On Monday 25 October 2010 06:06:15 Samuli Suominen (ssuominen) wrote:
> ssuominen 10/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.

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/

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.

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

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=261&r2=288

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.

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

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?

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