Just as the summary says, this package lacks the standard fix. On not quite related note, gstreamer 1.4 ebuilds for gst-plugins-bad, gst-plugins-good, gst-plugins-ugly and gst-plugins-libav should import and adapt fix for the same problem from gst-plugins-base, but as the maintainer has expressed the lack of interest in fixing this when prompted on irc, I don't know where should I push it further.
(In reply to Rafał Mużyło from comment #0) > Just as the summary says, this package lacks the standard fix. > > On not quite related note, gstreamer 1.4 ebuilds for gst-plugins-bad, > gst-plugins-good, gst-plugins-ugly and gst-plugins-libav should import and > adapt fix for the same problem from gst-plugins-base, but as the maintainer > has expressed the lack of interest in fixing this when prompted on irc, I > don't know where should I push it further. Report it as a bug report (assigned to gstreamer herd) to ensure that is not forget... and if you provide the concrete patch or link that needs to be done, it would be even better :) Thanks
@comment 1: ...you do realize that: 1. effectively only leio has been doing major bumps, even if you are listed in the herd too (or at least gstreamer 1.4 was waiting for a few months till he got around to doing the bump) and he was the one I meant 2. the nature of those fixes makes them pretty much copy-pastes, the only adjustment in gstreamer case is that some of those listed don't have 'libs' dir ? ?
1. you are badly mistaken, I think I can be credited for the whole 1.0 and 1.2 bumps at least plus gst-rtsp-server a couple of days ago, in any case, if you want to join the effort, you know the drill "I want to become a dev guide", and we will be happy to welcome you on the team. 2. just like bug reporting is a barrier, a ticket without a patch is another one. The fix is simple but applying a patch is even simpler :)
While I'm quite aware that I've spent more time ranting about it than it would take to produce those trivial patches, the very fact that they're are *trivial* makes me still unwilling to go another way about it. It's one thing to hold hand of a newbie user (that, I can do if the fancy strikes me on the forum)...
Created attachment 403074 [details] an old irc log ...and not to mention two other details: first is this irc log, the second - see the first entry of bug 517672.
(In reply to Rafał Mużyło from comment #2) > @comment 1: > > ...you do realize that: > 1. effectively only leio has been doing major bumps, even if you are listed > in the herd too (or at least gstreamer 1.4 was waiting for a few months till > he got around to doing the bump) and he was the one I meant > You clearly need to review ChangeLogs more deeply, and not only from the main gstreamer package, but also to the splitted plugins. > 2. the nature of those fixes makes them pretty much copy-pastes, the only > adjustment in gstreamer case is that some of those listed don't have 'libs' > dir ? > > ? In summary... if I come back after hours of work and I see all this discussion and blames instead of the simply fix that is needed, it doesn't help at all to get it solved sooner :| (specially when I need to review many more bug reports from other areas/teams)
The point of my rant is that this shouldn't ever have been a problem. The log is from the time when gstreamer was being rewritten to multilib ebuilds - this problem did *not* exist before. Then, as I've made the 0-day bump, I've reminded you people about what I've said back in the chat. Yet six months later, when gstreamer 1.4 went into the tree, that part was *again* ignored. Now, I'm getting more of the same spiel. > You clearly need to review ChangeLogs more deeply, and not only from the main gstreamer package, but also to the splitted plugins. On that point, did you note that the old gst-plugins-gl had 'libvisual' useflag, back in bug 517672, I've added it in my hackish update to gst-plugins-bad ebuild, yet the version that got into the tree didn't gain it ? It should probably be under 'REQUIRED_USE="libvisual? ( opengl )', still...
Well, with proper bug reports that would probably help in not forgetting about it.
(In reply to Gilles Dartiguelongue from comment #8) > Well, with proper bug reports that would probably help in not forgetting > about it. FFS, take a look at my attachment in bug 517672 - it *had* that gtk-doc snippet !!! Minor differences in -ugly ebuild not withstanding, only other adjustment would be that 'libs' thing - other than that it's copy-paste. I'm getting the feeling I'd get better results talking to a stone wall - at least I could kick it.
It's a bump report. Things got missed, fine, open a new one. Please understand that we are not perfect and don't always have the time to extend our work to things that get buried in the comments after a while. A report for a specific problem for a specific packages has more chance to be treated correctly. That's my experience and imho logical. Anyway, this is not a forum so I'll stop commenting on your other problems here and concentrate on gdk-pixbuf.
> Things got missed ...or got ignored when they could be done right right from the start. The way I read this, it's "keep fixing the ebuilds in your local overlay". Thank you for your cooperation, then.
+*gdk-pixbuf-2.30.8-r1 (01 Aug 2015) + + 01 Aug 2015; Alexandre Rostovtsev <tetromino@gentoo.org> + +gdk-pixbuf-2.30.8-r1.ebuild, +files/gdk-pixbuf-2.30.8-divide-by-zero.patch, + +files/gdk-pixbuf-2.30.8-pixops-overflow.patch: + Fix integer overflow in pixops (bug #556314, thanks to Agostino Sarubbo). Fix + gtk-doc installation (bug #549166, thanks to Rafał Mużyło).
