FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 10-25-2010, 09:50 PM
Alexis Ballier
 
Default 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:
> 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.
 
Old 10-25-2010, 10:06 PM
Diego Elio Pettenò
 
Default 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/
 
Old 10-25-2010, 10:17 PM
Alexis Ballier
 
Default 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.
 
Old 10-26-2010, 03:11 PM
Mike Frysinger
 
Default gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch

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
 
Old 10-26-2010, 03:26 PM
Samuli Suominen
 
Default 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=261&r2=288
 
Old 10-28-2010, 02:13 PM
Alexis Ballier
 
Default 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.
 
Old 10-28-2010, 05:42 PM
Mike Frysinger
 
Default 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
 
Old 10-28-2010, 05:51 PM
"Paweł Hajdan, Jr."
 
Default 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?
 
Old 11-09-2010, 10:40 PM
Mike Frysinger
 
Default 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
 

Thread Tools




All times are GMT. The time now is 11:57 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org