Arches, Please test and mark stable =media-video/mkvtoolnix-3.4.0 Thanks!
I hit bug #311595 when testing on stable x86 system.
CC the arches back when the blocking bug is fixed
(In reply to comment #2) > CC the arches back when the blocking bug is fixed > 2 stablereqs and a gcc bug? nothing really blocking imho, besides fixing the stable toolchain... waiting the gcc bug to be fixed, you could check if passing --disable-precompiler-headers to configure helps
ppc stable
(In reply to comment #3) > 2 stablereqs and a gcc bug? nothing really blocking imho, besides fixing the > stable toolchain... > waiting the gcc bug to be fixed, you could check if passing > --disable-precompiler-headers to configure helps I'm not sure how soon the GCC bug will be fixed. I have just tested with gcc-4.4.4-r2. Does it work with ~arch gcc? How about making the flac dependency mandatory for stabilization? (i.e. remove the USE flag and always depend on flac)
(In reply to comment #3) > (In reply to comment #2) > > CC the arches back when the blocking bug is fixed > > > > 2 stablereqs and a gcc bug? nothing really blocking imho, besides fixing the > stable toolchain... > waiting the gcc bug to be fixed, you could check if passing > --disable-precompiler-headers to configure helps > What are you talking about? You package is broken when using USE="-flac". Instead of waiting for gcc to be fixed, you can always drop this flag. This package fails to build and we ain't going to make it stable
(In reply to comment #6) > (In reply to comment #3) > > (In reply to comment #2) > > > CC the arches back when the blocking bug is fixed > > > > > > > 2 stablereqs and a gcc bug? nothing really blocking imho, besides fixing the > > stable toolchain... > > waiting the gcc bug to be fixed, you could check if passing > > --disable-precompiler-headers to configure helps > > > > What are you talking about? You package is broken when using USE="-flac". > Instead of waiting for gcc to be fixed, you can always drop this flag. This > package fails to build and we ain't going to make it stable > To follow your aggressive tone: You know, there are bugs marked as dependencies for this one, take your mouse, click the link, read it. A gcc ICE, usually, has nothing to do with the package failing... On a more serious tone: I can understand you don't want to mark stable a package that fails to compile, unfortunately there is nothing we can do on the mkvtoolnix side. If you haven't acted within, say 2 weeks, I'll drop to ~amd64 all the mkvtoolnix ebuilds and everything in this list too: http://tinderbox.dev.gentoo.org/misc/rindex/media-video/mkvtoolnix Also, I haven't heard about any testing without precompiled headers. You may want to try with 4.4.0 with its pch useflag and mask the broken combinations accordingly. If you think dropping the flac useflag is a solution, I don't. Feel free to fill _your_ package.use.force file in _your_ profile though. In the end, there seems to be many possible solutions, but you don't appear to be interested in discussing them and prefer to remove yourself from cc. If you do this again, I'll take it as a full ack for my solution of dropping everything to ~arch.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #3) > > > (In reply to comment #2) > > > > CC the arches back when the blocking bug is fixed > > > > > > > > > > 2 stablereqs and a gcc bug? nothing really blocking imho, besides fixing the > > > stable toolchain... > > > waiting the gcc bug to be fixed, you could check if passing > > > --disable-precompiler-headers to configure helps > > > > > > > What are you talking about? You package is broken when using USE="-flac". > > Instead of waiting for gcc to be fixed, you can always drop this flag. This > > package fails to build and we ain't going to make it stable > > > > To follow your aggressive tone: > You know, there are bugs marked as dependencies for this one, take your mouse, > click the link, read it. A gcc ICE, usually, has nothing to do with the package > failing... > > On a more serious tone: > I can understand you don't want to mark stable a package that fails to compile, > unfortunately there is nothing we can do on the mkvtoolnix side. If you haven't > acted within, say 2 weeks, I'll drop to ~amd64 all the mkvtoolnix ebuilds and > everything in this list too: > http://tinderbox.dev.gentoo.org/misc/rindex/media-video/mkvtoolnix > > Also, I haven't heard about any testing without precompiled headers. You may > want to try with 4.4.0 with its pch useflag and mask the broken combinations > accordingly. > > If you think dropping the flac useflag is a solution, I don't. Feel free to > fill _your_ package.use.force file in _your_ profile though. > > In the end, there seems to be many possible solutions, but you don't appear to > be interested in discussing them and prefer to remove yourself from cc. If you > do this again, I'll take it as a full ack for my solution of dropping > everything to ~arch. > That way you ship a broken package to the users. It might not be directly related to mkvtoolnix however when the end-user will try to use USE="-flac" emerge mkvtoolnix will see the bug right in front of his face. Since mkvtoolnix cannot build with that flag disabled why don't you just drop it afterall? Whats the point of having that use flag anyway. The tone is not as aggressive as you might think. I am just curious why you want to ship a package that fails to build under known circumstances. If you insist on keeping this useflag around, I will mask it for amd64 and proceed with the stabilization. But I guess this will disable the flac functionality which is not the optimal solution. My suggestion is to drop flac use flag, hardcode --enable-flac ( or whatever ) in your ebuild and everyone will be happy. You might not be happy but users will
(In reply to comment #8) > That way you ship a broken package to the users. You should have refused to stabilise this gcc version then. The mkvtoolnix bug was opened 7 months before gcc-4.4.4-r2 was stabilised... You already ship a broken compiler, the fact that some useflags combinations in mkvtoolnix triggers it is only bad luck. [...] > If you insist on keeping this useflag around, I will mask it for amd64 and > proceed with the stabilization. But I guess this will disable the flac > functionality which is not the optimal solution. We're talking about forcing it, that's the p.use.force solution. It will not disable functionality but rather force it on while I'm sure a minority of users will use it. > > My suggestion is to drop flac use flag, hardcode --enable-flac ( or whatever ) > in your ebuild and everyone will be happy. You might not be happy but users > will > That way arches shipping a non-broken compiler will also force it...
USE="pch" emerge mkvtoolnux-4.4.0 builds fine using stable and testing toolchain. Wanna change the target? Requires new libmatroska and libebml as well
(In reply to comment #10) > USE="pch" emerge mkvtoolnux-4.4.0 builds fine using stable and testing > toolchain. Wanna change the target? Requires new libmatroska and libebml as > well > That's weird its working fine... Changing the target could be an option, yes. Maybe we can close this bug as later then. Newer libebml & libmatroska shouldn't be a problem.
(In reply to comment #11) > (In reply to comment #10) > > USE="pch" emerge mkvtoolnux-4.4.0 builds fine using stable and testing > > toolchain. Wanna change the target? Requires new libmatroska and libebml as > > well > > > > That's weird its working fine... Changing the target could be an option, yes. > Maybe we can close this bug as later then. Newer libebml & libmatroska > shouldn't be a problem. > Well 4.4.0 is 3 months on tree. I think it is safe to update the target
(In reply to comment #12) > Well 4.4.0 is 3 months on tree. I think it is safe to update the target I agree and fixed a minor QA warning with wxwidgets for 4.4.0 as I was bumping to 4.5.0. Arches, please test and mark stable: =media-video/mkvtoolnix-4.4.0 and its dependencies: =dev-libs/libebml-1.0.0 =media-libs/libmatroska-1.0.0
seems ok on amd64!
Builds fine on x86. Rdeps build fine. Don't know how to test in detail, ran mkvinfo and it gave the help (as expected). Seems ok to me. Please mark stable for x86.
x86 stable, thanks Myckel
amd64 done. Thanks Agostino
ppc done; closing as last arch
