Summary: | media-video/cinelerra-20140710 stable request (was: media-video/cinelerra-20120707 : qtffmpeg.c:42:18: error: ‘CODEC_ID_SVQ1’ undeclared (first use in this function)) | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> | ||||||||
Component: | Stabilization | Assignee: | Gentoo Media-video project <media-video> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | normal | CC: | atoth, treecleaner | ||||||||
Priority: | Normal | Keywords: | STABLEREQ | ||||||||
Version: | unspecified | Flags: | stable-bot:
sanity-check+
|
||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Package list: |
=media-video/cinelerra-20140710
|
Runtime testing required: | --- | ||||||||
Bug Depends on: | |||||||||||
Bug Blocks: | 575538 | ||||||||||
Attachments: |
|
Description
Toralf Förster
2016-02-25 13:58:37 UTC
Created attachment 426526 [details]
emerge-history.txt
Created attachment 426528 [details]
environment
Created attachment 426530 [details]
media-video:cinelerra-20120707:20160225-083503.log
the "newer" and also obsolete version in the tree is still failing: bug 539920 CCing treecleaners (In reply to Pacho Ramos from comment #4) > the "newer" and also obsolete version in the tree is still failing: bug > 539920 > > CCing treecleaners lemme have a look at it (In reply to Pacho Ramos from comment #4) > the "newer" and also obsolete version in the tree is still failing: bug > 539920 > > CCing treecleaners This is for libav only. ffmpeg-3 is fine here. Let's stabilize the newer version. And... what about all the other opened bugs? :/ (In reply to Pacho Ramos from comment #7) > And... what about all the other opened bugs? :/ you mean the bug about a crash without sample nor backtrace ? bug 539920 depends on a bump that won't ever occur as it relies on someone packaging one of the available forks bug 567578 is the one I think you are referring to bug 585018 is another one And probably more will appear as this is dead for ages and I guess most people moved to other tools or forks (In reply to Pacho Ramos from comment #9) > bug 539920 depends on a bump that won't ever occur as it relies on someone > packaging one of the available forks cincv 2.3 could easily be bumped; i had a look at the others, they'll be much harder this certainly doesnt warrant a treeclean yet > bug 567578 is the one I think you are referring to yes > bug 585018 is another one libav only missing dep; it doesnt even build with a recent libav > And probably more will appear as this is dead for ages and I guess most > people moved to other tools or forks my crystal ball for bugs has broken :) cincv (the one we have in the tree and even advertised upstream) is one of those forks and seems to be the most stable one (In reply to Alexis Ballier from comment #10) > (In reply to Pacho Ramos from comment #9) > > bug 539920 depends on a bump that won't ever occur as it relies on someone > > packaging one of the available forks > > cincv 2.3 could easily be bumped; i had a look at the others, they'll be > much harder > > this certainly doesnt warrant a treeclean yet > Who is going to finally do that? Should we keep waiting for more years with that broken situation? > > bug 567578 is the one I think you are referring to > > yes closed asking for the backtrace > > > bug 585018 is another one > > libav only missing dep; it doesnt even build with a recent libav should we force ffmpeg usage then? We can do that instead of pretending it works with both (that is not the situation for a long time) > > > And probably more will appear as this is dead for ages and I guess most > > people moved to other tools or forks > > my crystal ball for bugs has broken :) > cincv (the one we have in the tree and even advertised upstream) is one of > those forks and seems to be the most stable one you could simply rely on previous experiences without needing a crystal ball (In reply to Pacho Ramos from comment #11) > (In reply to Alexis Ballier from comment #10) > > (In reply to Pacho Ramos from comment #9) > > > bug 539920 depends on a bump that won't ever occur as it relies on someone > > > packaging one of the available forks > > > > cincv 2.3 could easily be bumped; i had a look at the others, they'll be > > much harder > > > > this certainly doesnt warrant a treeclean yet > > > > Who is going to finally do that? see metadata.xml :) anyway, the above bug is about packaging another fork, so that'd be another $PN > Should we keep waiting for more years with > that broken situation? I don't consider a working package with an old snapshot broken. It certainly has room for improvement though. > > > > > bug 585018 is another one > > > > libav only missing dep; it doesnt even build with a recent libav > > should we force ffmpeg usage then? We can do that instead of pretending it > works with both (that is not the situation for a long time) probably yes > > > And probably more will appear as this is dead for ages and I guess most > > > people moved to other tools or forks > > > > my crystal ball for bugs has broken :) > > cincv (the one we have in the tree and even advertised upstream) is one of > > those forks and seems to be the most stable one > > you could simply rely on previous experiences without needing a crystal ball if it aint broken, dont fix it :) amd64 stable x86 stable. Closing. Well, you pointing to the metadata and trying to hide with that how this package is completely unattended on the tree for ages is enough for me I guess |