Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
On Thursday, October 28, 2010 13:51:05 Paweł Hajdan, Jr. wrote: On 10/28/10 7:42 PM, Mike Frysinger wrote: Il giorno lun, 25/10/2010 alle 18.50 -0300, Alexis Ballier ha scritto: Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... the maintainer already has done his due diligence and reviewed the field. at this point, it is *you* who disagrees with the situation thus it is *you* who needs to resolve *your* complaint. Just curious: what are the technical reasons for that? My understanding is that one header depends on another for proper compilation but doesn't #include it. Is that correct? the Linux guys are very averse to Linux headers pulling in things from the C library even though it probably makes sense to do so -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
On Tuesday 26 October 2010 12:11:50 Mike Frysinger wrote: On Monday, October 25, 2010 18:17:21 Alexis Ballier wrote: On Monday 25 October 2010 19:06:45 Diego Elio Pettenò wrote: Il giorno lun, 25/10/2010 alle 18.50 -0300, Alexis Ballier ha scritto: Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... Upstream seem not to care about fixing that; we used to have a patch to fix linux-headers, but Mike dropped it with 2.6.35 to stay as close to upstream as possible. so now we prefer poor workarounds in dozens of packages to fixing the real bug in a single one in order to stay as close as possible to an unresponsive upstream? nice you're free to argue the merits on lkml like anyone else. I thought this was maintainer's job... this package is going to be broken in pretty much every distro out there, so pushing limits.h to whichever package's upstream would be useful too. I'm sorry, I'm used to push patches I, _at least_, believe to be correct. In any case, there's nothing to argue on my side: you seem very well aware that because you're being lazy to fix the bugs and argue with upstream you are pushing stupid workarounds on others because said package happens to be widely used. Fortunately I never had to face such an issue, even though if I happen to, don't expect me to do anything else than forwarding the bug to the headers maintainers with a rant. A.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
On Thu, Oct 28, 2010 at 10:13 AM, Alexis Ballier wrote: On Tuesday 26 October 2010 12:11:50 Mike Frysinger wrote: On Monday, October 25, 2010 18:17:21 Alexis Ballier wrote: On Monday 25 October 2010 19:06:45 Diego Elio Pettenò wrote: Il giorno lun, 25/10/2010 alle 18.50 -0300, Alexis Ballier ha scritto: Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... Upstream seem not to care about fixing that; we used to have a patch to fix linux-headers, but Mike dropped it with 2.6.35 to stay as close to upstream as possible. so now we prefer poor workarounds in dozens of packages to fixing the real bug in a single one in order to stay as close as possible to an unresponsive upstream? nice you're free to argue the merits on lkml like anyone else. I thought this was maintainer's job... the maintainer already has done his due diligence and reviewed the field. at this point, it is *you* who disagrees with the situation thus it is *you* who needs to resolve *your* complaint. this package is going to be broken in pretty much every distro out there, so pushing limits.h to whichever package's upstream would be useful too. I'm sorry, I'm used to push patches I, _at least_, believe to be correct. In any case, there's nothing to argue on my side: you seem very well aware that because you're being lazy to fix the bugs and argue with upstream you are pushing stupid workarounds on others because said package happens to be widely used. Fortunately I never had to face such an issue, even though if I happen to, don't expect me to do anything else than forwarding the bug to the headers maintainers with a rant. you might want to look up some history before making stupid accusations -mike
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
On 10/28/10 7:42 PM, Mike Frysinger wrote: Il giorno lun, 25/10/2010 alle 18.50 -0300, Alexis Ballier ha scritto: Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... the maintainer already has done his due diligence and reviewed the field. at this point, it is *you* who disagrees with the situation thus it is *you* who needs to resolve *your* complaint. Just curious: what are the technical reasons for that? My understanding is that one header depends on another for proper compilation but doesn't #include it. Is that correct? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
On 10/26/2010 06:11 PM, Mike Frysinger wrote: On Monday, October 25, 2010 18:17:21 Alexis Ballier wrote: On Monday 25 October 2010 19:06:45 Diego Elio Pettenò wrote: Il giorno lun, 25/10/2010 alle 18.50 -0300, Alexis Ballier ha scritto: Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... Upstream seem not to care about fixing that; we used to have a patch to fix linux-headers, but Mike dropped it with 2.6.35 to stay as close to upstream as possible. so now we prefer poor workarounds in dozens of packages to fixing the real bug in a single one in order to stay as close as possible to an unresponsive upstream? nice you're free to argue the merits on lkml like anyone else. this package is going to be broken in pretty much every distro out there, so pushing limits.h to whichever package's upstream would be useful too. -mike for this particular package, it's already fixed in trunk http://mpfc.svn.sourceforge.net/viewvc/mpfc/trunk/plugins/input/audiocd/audiocd.c?r1=261r2=288
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
On Monday 25 October 2010 06:06:15 Samuli Suominen (ssuominen) wrote: ssuominen10/10/25 09:06:15 Added:mpfc-1.3.7-INT_MAX.patch Log: Missing include limits.h, required by recent linux-headers for cdrom.h and INT_MAX. Fix installation with recent coreutils wrt #335449 by Diego E. Pettenò. [...] #include stdio.h +#include limits.h /* cdrom.h and INT_MAX */ #include linux/cdrom.h #include errno.h #include string.h Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... This comes to my mind too: http://blog.flameeyes.eu/2009/02/04/brace-for-impact A.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
Il giorno lun, 25/10/2010 alle 18.50 -0300, Alexis Ballier ha scritto: Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... Upstream seem not to care about fixing that; we used to have a patch to fix linux-headers, but Mike dropped it with 2.6.35 to stay as close to upstream as possible. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
On Monday 25 October 2010 19:06:45 Diego Elio Pettenò wrote: Il giorno lun, 25/10/2010 alle 18.50 -0300, Alexis Ballier ha scritto: Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... Upstream seem not to care about fixing that; we used to have a patch to fix linux-headers, but Mike dropped it with 2.6.35 to stay as close to upstream as possible. so now we prefer poor workarounds in dozens of packages to fixing the real bug in a single one in order to stay as close as possible to an unresponsive upstream? nice A. PS: What to do if there is a clever upstream for another package refusing to add such a workaround ? Carry the patch over and over ? This sounds very selfish.
