[opensuse-factory] Please don't submit ffmpeg-3.1.2
There's a new release of ffmpeg, please don't submit it until ffmpeg -3.1.1 is accepted to Factory otherwise things are going to get even more out of sync in the multimedia world Thanks Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2016-08-09 at 13:31 +0200, Dave Plater wrote:
There's a new release of ffmpeg, please don't submit it until ffmpeg -3.1.1 is accepted to Factory otherwise things are going to get even more out of sync in the multimedia world
I doubt this will ever be accepted - I already stated on the submit req that this is the worst idea ever attempted. VLC 2.2.x does not build with this version of ffmpeg - any 3rd party BS that does it proper will link ffmpeg and VLC from the same location (openSUSE:Factory) - having the two not co-work together is just calling for disaster. Cheers, Dominique
There's a new release of ffmpeg, please don't submit it until ffmpeg -3.1.1 is accepted to Factory otherwise things are going to get even more out of sync in the multimedia world I doubt this will ever be accepted - I already stated on the submit req
On Tue, 2016-08-09 at 13:31 +0200, Dave Plater wrote: that this is the worst idea ever attempted.
VLC 2.2.x does not build with this version of ffmpeg - any 3rd party BS that does it proper will link ffmpeg and VLC from the same location (openSUSE:Factory) - having the two not co-work together is just calling for disaster.
Cheers, Dominique vlc-beta ? The codecs for vlc will always have to be built separately otherwise vlc will be useless as a video player. The codec package builds against ffmpeg-2.8 with no problem and vlc in obs builds fine with either ffmpeg abi. Maybe an ffmpeg-2.8 in multimedia:libs is actually the solution to the problem or a switch to vlc-beta. Vlc is the only package that doesn't build with ffmpeg3. Is there a problem with
On 09/08/2016 13:37, Dominique Leuenberger / DimStar wrote: the codec package? There must be a solution somewhere. Regards Dave -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2016-08-09 20:18, Dave Plater wrote:
VLC 2.2.x does not build with this version of ffmpeg - any 3rd party BS that does it proper will link ffmpeg and VLC from the same location (openSUSE:Factory) - having the two not co-work together is just calling for disaster. Maybe an ffmpeg-2.8 in multimedia:libs is actually the solution to the problem
Well, I already proposed an ffmpeg2 package in the comment section of the currently-active ffmpeg(3) SR that factory-autosubmit sent to factory. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 09.08.2016 um 20:18 schrieb Dave Plater:
There must be a solution somewhere.
There could be pkgs which link to "libvlc" and "libffmpeg" at the same time, either directly or via dependencies. With two "libffmpeg" variants linked in, which one will be used? This is probably the "disaster" mentioned earlier. So the solution is: get everything ready for v3. If there is no such "disaster", just move on and get v3 into Factory. Noone cares about non-OBS buildservices either for all the other packages which get thrown into Factory. ffmpeg is not special. Olaf
On Tuesday 2016-08-09 22:17, Olaf Hering wrote:
Am 09.08.2016 um 20:18 schrieb Dave Plater:
There must be a solution somewhere.
There could be pkgs which link to "libvlc" and "libffmpeg" at the same time, either directly or via dependencies. With two "libffmpeg" variants linked in, which one will be used?
Unlike libldap and libldap_r (something that currently ruins my day in another project), libav* uses symbol versions, so it is defined which functions get used. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2016-08-09 at 22:17 +0200, Olaf Hering wrote:
If there is no such "disaster", just move on and get v3 into Factory. Noone cares about non-OBS buildservices either for all the other packages which get thrown into Factory. ffmpeg is not special.
I object of producing a dump of many packages - with any package, if somebody raises an issue to be seen against other packages that are of importance, Tumbleweed Release Managers try to take this into account. This is for example the reason why legacy packages like pangox stayed around for so long - nothing in the distro cared for it, but sound reasons were given that 3rd parties rely on it and in an attempt to not make this more complicated / error prone, it remained. ffmpeg is no different - knowing that we break multimedia packages in 2 well-known 4rd party OBS instances is definitive reason enough for me - and I have still not heard a good reason for ffmpeg 3.x other the fact that it has a higher version number. Cheers, Dominique
On 10.08.2016 17:21, Dominique Leuenberger / DimStar wrote:
On Tue, 2016-08-09 at 22:17 +0200, Olaf Hering wrote:
If there is no such "disaster", just move on and get v3 into Factory. Noone cares about non-OBS buildservices either for all the other packages which get thrown into Factory. ffmpeg is not special.
I object of producing a dump of many packages - with any package, if somebody raises an issue to be seen against other packages that are of importance, Tumbleweed Release Managers try to take this into account.
This is for example the reason why legacy packages like pangox stayed around for so long - nothing in the distro cared for it, but sound reasons were given that 3rd parties rely on it and in an attempt to not make this more complicated / error prone, it remained.
ffmpeg is no different - knowing that we break multimedia packages in 2 well-known 4rd party OBS instances is definitive reason enough for me - and I have still not heard a good reason for ffmpeg 3.x other the fact that it has a higher version number.
Cheers, Dominique
Are you seriously arguing for obsolete packages in a supposedly "rolling" distribution while having 2 potential solutions presented: 1) Updating or fixing the actual broken package; 2) Backporting fixes for broken package or keeping its old dependency (which, being a library framework, supports parallel installation of multiple versions) ? And the counter-argument against you is "Noone cares about non-OBS buildservices", "ffmpeg is not special." ? I don't even know which one is more baffling. I wonder, do any of you actually using your personal system without multimedia apps at all ? Do you even have X-server installed ? Anyway, if the real issue is with VLC, then you shouldn't bother with too many hacks or risk ffmpeg bitrotting. VLC maybe popular on Windows but it's just too damn clunky and slow-developing. Unless vlc-beta isn't working _and_ there is no patches to backport, don't even waste time pondering, update ffmpeg !
On Wed, 2016-08-10 at 19:55 +0500, Sergey Kondakov wrote:
Are you seriously arguing for obsolete packages in a supposedly "rolling" distribution while having 2 potential solutions presented:
I'm arguing at a distribution level - not at a package level.
1) Updating or fixing the actual broken package;
Have a go at it and submit it - don't demand for fixes to happen
2) Backporting fixes for broken package or keeping its old dependency (which, being a library framework, supports parallel installation of multiple versions) ?
This was already stated by me as acceptable - but nobody seems to be willing to do the work But I take this as 'VLC is obsolete and should be removed from the distribution'? Fine by me... There is no VLC out yet that supports the new API - backporting the diff from the 3.0 branch is not straight forward. And I'm sure I can use this argumentation to drop anything that stops building at any moment in the future, right? because 'we are rolling' we don't care for things that can't keep up with the pace?
And the counter-argument against you is "Noone cares about non-OBS buildservices", "ffmpeg is not special." ?
Which I countered by 'it's not true' - read all my text, not only the pieces that interest you
I don't even know which one is more baffling. I wonder, do any of you actually using your personal system without multimedia apps at all ? Do you even have X-server installed ?
What? do any of us use a personal system WITHOUT multimedia apps? you must be confused, so I'll answer as if you would have asked 'WITH multimedia apps' Yes, I even regularly use VLC (amongst others) and do not want it to be broken - including the addon codecs - by bringing a package in the distribution that obviously breaks it. And I do not want to have the two well-known 3rd party OBS instances break my system when I add their packages. There is sufficient trouble with addon repos without forcing it.
Anyway, if the real issue is with VLC, then you shouldn't bother with too many hacks or risk ffmpeg bitrotting. VLC maybe popular on Windows but it's just too damn clunky and slow-developing. Unless vlc-beta isn't working _and_ there is no patches to backport, don't even waste time pondering, update ffmpeg !
Again: I take this as request to drop VLC - I'm fine with this approach too.... but I do not want to hear any complaints from anywhere. Cheers, Dominique
On 10.08.2016 20:13, Dominique Leuenberger / DimStar wrote:
On Wed, 2016-08-10 at 19:55 +0500, Sergey Kondakov wrote:
Are you seriously arguing for obsolete packages in a supposedly "rolling" distribution while having 2 potential solutions presented:
I'm arguing at a distribution level - not at a package level.
1) Updating or fixing the actual broken package;
Have a go at it and submit it - don't demand for fixes to happen
Personally, I don't need fixes for vlc, I hate it. All those features, buttons and menus but none of them useful, unlike mpv. Other apps may soon start demanding fresh ffmpeg. It's funny how you wouldn't allow "my" packages to be updated until I "fix" "yours" all while you know several ways to do so better than I am and had a bunch of time of prior notice.
2) Backporting fixes for broken package or keeping its old dependency (which, being a library framework, supports parallel installation of multiple versions) ?
This was already stated by me as acceptable - but nobody seems to be willing to do the work
Backporting from that will probably would be like doing so from Firefox. A mess. What work exactly has to be made to copy Factory's ffmpeg as ffmpeg2 and set dependency version in "stable" package of VLC ? Can't you do it instead of halting entirety of A/V stack for weeks or months for the package that has its non-released version fine and working ? Although, when I was doing something similar, OBS tried to ignore any ffmpeg version other than the latest. Is there a way to feed it ffmpeg 2.x tarball as its "contrib" version via spec so it would build it and statically link with it or whatever it does by default ? If so and this is upstream's attitude - https://trac.videolan.org/vlc/ticket/17248, that probably should be default for "stable" vlc package because of how lazily it updates and how small its improvements are.
But I take this as 'VLC is obsolete and should be removed from the distribution'? Fine by me... There is no VLC out yet that supports the new API - backporting the diff from the 3.0 branch is not straight forward.
And I'm sure I can use this argumentation to drop anything that stops building at any moment in the future, right? because 'we are rolling' we don't care for things that can't keep up with the pace?
This is not what I said, I said: keep working bleeding edge version as primary until working release, backport from it or keep its dependency until update. You argue for neither. I already got a taste of you people not fixing and just dropping packages left and right. Even working ones. How this even supposed to be tested if ffmpeg 3.x is currently broken because https://build.opensuse.org/request/show/417360 isn't merged but https://build.opensuse.org/request/show/415435 was ?
And the counter-argument against you is "Noone cares about non-OBS buildservices", "ffmpeg is not special." ?
Which I countered by 'it's not true' - read all my text, not only the pieces that interest you
And so do you.
I don't even know which one is more baffling. I wonder, do any of you actually using your personal system without multimedia apps at all ? Do you even have X-server installed ?
What? do any of us use a personal system WITHOUT multimedia apps? you must be confused, so I'll answer as if you would have asked 'WITH multimedia apps'
Yes, I even regularly use VLC (amongst others) and do not want it to be broken - including the addon codecs - by bringing a package in the distribution that obviously breaks it. And I do not want to have the two well-known 3rd party OBS instances break my system when I add their packages. There is sufficient trouble with addon repos without forcing it.
No, you're the one confused, I wrote "without" and I meant it. Because consistently so little care is given by most official maintainers to fundamental A/V support, that you must be using useless, gutted builds for multimedia or none at all. Therefore I wonder if people who do either even really exist and, if so, which is it. But then again, a distribution installer was dropped form its repo. So what is measly A/V support after that ? Might as well drop kernel or build it with all modules disabled. Argh, if I had any I would pay billions to buy out, move it to Russia and develop open/SUSE and/or Sailfish as desktop/mobile enduser no-bell-and-whistles distribution to rival MacOS. Just so it would be 100% maintained and developed full-time.
Anyway, if the real issue is with VLC, then you shouldn't bother with too many hacks or risk ffmpeg bitrotting. VLC maybe popular on Windows but it's just too damn clunky and slow-developing. Unless vlc-beta isn't working _and_ there is no patches to backport, don't even waste time pondering, update ffmpeg !
Again: I take this as request to drop VLC - I'm fine with this approach too.... but I do not want to hear any complaints from anywhere.
Cheers, Dominique
If you've accepted ffmpeg 3.x break-inducing hdf5 update into Factory, you can sit on broken stable vlc just until its update since you will even have working unstable version in the meantime. Or bother to copy 1 already in-Factory package temporary instead of arguing in kilobytes of mail. That's why I, as many others, rarely commit anything into Factory, spares the "banter" with people who keen on breaking but not so much on fixing even for themselves. So don't twist my words into encouragement of typical openSUSE drop-frenzy.
Am Mittwoch, 10. August 2016, 22:58:39 schrieb Sergey Kondakov:
How this even supposed to be tested if ffmpeg 3.x is currently broken because https://build.opensuse.org/request/show/417360 isn't merged but https://build.opensuse.org/request/show/415435 was ?
In case you haven't noticed, https://build.opensuse.org/request/show/417360 has been accepted to Factory yesterday. And I think it's more the "fault" of the science maintainer who submitted hdf5 to Factory in the first place, despite it breaking netcdf (which is also maintained in the science repo). I suppose staging should have caught that though and prevent its acception, no idea what went "wrong" there. But pointing at people doesn't help anyway. Btw, I'm only replying here because I submitted the fix for netcdf last Saturday after noticing that it is broken (it caused problems in KDE:Extra too). I don't want to get engaged in this "discussion" really... Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 10. August 2016, 21:19:15 schrieb Wolfgang Bauer:
In case you haven't noticed, https://build.opensuse.org/request/show/417360 has been accepted to Factory yesterday.
Oops, sorry. It isn't accepted to Factory yet, only the review got accepted by Dominique yesterday. No idea where I looked... Still, I submitted that fix after the hdf5 update was already in Factory. So it is not a question why the first one has been accepted and this one not (yet). Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2016-08-10 at 21:36 +0200, Wolfgang Bauer wrote:
Am Mittwoch, 10. August 2016, 21:19:15 schrieb Wolfgang Bauer:
In case you haven't noticed, https://build.opensuse.org/request/sho w/417360 has been accepted to Factory yesterday.
Oops, sorry. It isn't accepted to Factory yet, only the review got accepted by Dominique yesterday. No idea where I looked...
It was not accepted as it ended up in a group together with netcdf-cxx, which is a new package and thus pending legal review. In an attempt to speed this up I broke the group apart - this in turn allowed netcdf (and parallel-netcdf) to leave the staging area. Even though there was already a checkin round today I now accepted netcdf into openSUSE:Factory too; the setback for the building power is minimal. Cheers, Dominique
On 2016/8/11 上午 03:19, Wolfgang Bauer wrote:
Am Mittwoch, 10. August 2016, 22:58:39 schrieb Sergey Kondakov:
How this even supposed to be tested if ffmpeg 3.x is currently broken because https://build.opensuse.org/request/show/417360 isn't merged but https://build.opensuse.org/request/show/415435 was ?
In case you haven't noticed, https://build.opensuse.org/request/show/417360 has been accepted to Factory yesterday.
And I think it's more the "fault" of the science maintainer who submitted hdf5 to Factory in the first place, despite it breaking netcdf (which is also maintained in the science repo). I suppose staging should have caught that though and prevent its acception, no idea what went "wrong" there.
It just because netcdf haven't in the Rings therefor also not in the Staging too, so when hdf in the staging we can't see netcdf is build failed. Regards, Max -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 11. August 2016, 03:37:58 schrieb Max Lin:
It just because netcdf haven't in the Rings therefor also not in the Staging too, so when hdf in the staging we can't see netcdf is build failed.
Regards, Max
Am Mittwoch, 10. August 2016, 21:43:02 schrieb Dominique Leuenberger / DimStar:
Hope that clarifies how hdf5 got through staging - despite breaking netcdf.
Cheers, Dominique
It does, for me at least. Thank you both for the explanations! Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2016-08-10 at 21:19 +0200, Wolfgang Bauer wrote:
And I think it's more the "fault" of the science maintainer who submitted hdf5 to Factory in the first place, despite it breaking netcdf (which is also maintained in the science repo). I suppose staging should have caught that though and prevent its acception, no idea what went "wrong" there.
hdf5 is a ring package and as such only went through staging - netcdf on the other hand is not in a ring and is thus not considered vital to hold back anything else from breaking it. ffmpeg at the day of submission of hdf5 did not depend on netcdf - so the fact that it now does not build was introduced after hdf5 had been tested against ffmpeg in the distro. Hope that clarifies how hdf5 got through staging - despite breaking netcdf. Cheers, Dominique
Hope that clarifies how hdf5 got through staging - despite breaking netcdf.
Thanks for the lengthly explanation, the question I have now is how or is netcdf into a ring And how to put some other into rings : I'm thinking about impacted package by hdf5/netcdf breakage, like gdal ... -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2016-08-11 at 09:22 +0200, Bruno Friedmann wrote:
Hope that clarifies how hdf5 got through staging - despite breaking netcdf.
Thanks for the lengthly explanation, the question I have now is how or is netcdf into a ring
And how to put some other into rings : I'm thinking about impacted package by hdf5/netcdf breakage, like gdal ...
The rings are formost defined to be the things that end up on the DVD - which is basically 'the two main desktops plus their dependencies' If there is a compelling reason to get anything into the ring, it can be discussed. But being promoted to be a ring package cannot happen at a time when a package does not build. Packages entering the ring have to be of 'some importance' at least. Keep in mind that wildly putting things into rings makes the staging process longer and thus will take more time for packages to be able to enter Tumbleweed. If we were to test all ~9000 packages, we would likely come to a grinding halt. Cheers, Dominique
On jeudi, 11 août 2016 09.32:00 h CEST Dominique Leuenberger / DimStar wrote:
On Thu, 2016-08-11 at 09:22 +0200, Bruno Friedmann wrote:
Hope that clarifies how hdf5 got through staging - despite breaking netcdf.
Thanks for the lengthly explanation, the question I have now is how or is netcdf into a ring
And how to put some other into rings : I'm thinking about impacted package by hdf5/netcdf breakage, like gdal ...
The rings are formost defined to be the things that end up on the DVD - which is basically 'the two main desktops plus their dependencies'
If there is a compelling reason to get anything into the ring, it can be discussed. But being promoted to be a ring package cannot happen at a time when a package does not build. Packages entering the ring have to be of 'some importance' at least.
Keep in mind that wildly putting things into rings makes the staging process longer and thus will take more time for packages to be able to enter Tumbleweed. If we were to test all ~9000 packages, we would likely come to a grinding halt.
Cheers, Dominique
Thanks for the (redone version 1000) of the explanation. And make it clear, that we have to find a right balance between pushing all packages to Factory, and the non (still) ability to test their correct integration as a whole : which is the main objective of TW. I like science when some "vodoo" is needed to make it work ;-) Thanks to be our warlock actually :-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2016-08-11 12:06, Bruno Friedmann wrote:
I like science when some "vodoo" is needed to make it work ;-)
Magic is just another word for indistinguishable advanced technology :D And we want the tech… -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Bruno Friedmann -
Dave Plater -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Max Lin -
Olaf Hering -
Sergey Kondakov -
Wolfgang Bauer