On Thu, Apr 20, 2017 at 8:27 PM, Mauro Santos via arch-general <arch-general@xxxxxxxxxxxxx> wrote: > On 20-04-2017 20:21, Ralf Mardorf wrote: >>> Have you reported the bug? If yes and the dev decides that it should be >>> reverted to a previous version there is a way to do it, see: >>> man pacman | grep -A1 epoch >> >> For the sake of completeness: >> >> "Upstream or Arch? >> [snip] >> If Arch is not responsible for a bug, the problem >> will not be solved by reporting the bug to Arch developers." - >> https://wiki.archlinux.org/index.php/Reporting_bug_guidelines#Upstream_or_Arch.3F >> >> This policy isn't always pleasant ;), but the Arch developers sometimes >> are willing to balance pros and cons, so sometimes they fix such >> issues ;). >> > > Maybe I should have been more specific, I was talking about > downgrading/reverting an update. That is why the epoch field exists and > it has been used before. Ffmpeg does have the mark of shame already so I > suppose sometime in the past it has been necessary to do a downgrade. > > In the case where the bug comes from upstream one should report it > upstream, but if it is something "serious" you have to report it in > Arch's bug tracker, the maintainer does not have a crystal ball to know > some nasty bug reared its head. Bug has been reported in Arch's tracker and there's a companion bug from someone else about ffmpeg2.8. It makes sense to report in Arch first because arch has published 3.3 in testing and maybe ffmpeg's version scheme is just convoluted and 3.3 is unstable while 2.8 and 3.2 (even numbers) were stable branches. ffmpeg.org doesn't label 3.3 as a dev branch so I don't blame arch for picking ffmpeg3.3. In fact it says 3.3 is a stable release. The corruption is easy to reproduce and so obvious that I didn't consider reporting it to ffmpeg.org. It looks impossible to slip their tests. I'm using ffmpeg 2.8.11 now, but since it's dangerous for other users to have their files corrupted, I think an official downgrade to 3.2.4 is in order.
