Hi Heinz Wiesinger: "From my point of view, those two should not be updated that often." Hahahaha :) trust me, they are not updated "that" often, this would be their first update since 8 months ago.
" I first thought about an update right after the release of a new Slackware-version," Before the release of Slackware 12.1 that was i wanted to do, also i asked to rworkman if that would be possible (if i can remember, all he said me is(more or less) "wait for the maintainer consideration") but anyway, I still have the idea that apps from svn/cvs should be updated right after a Slackware release, so we can use them like in 1 year without worry of them ;) "As MPlayer is using ffmpeg internally we can probably state that the version used by MPlayer is pretty stable." It's that, or we can state that they are pretty different too. Are the changes made by MPlayer to ffmpeg(the internal) also done in ffmpeg(the official)? "MPlayer is also adjusting the interface to x264 in svn, which means that the perfect combination of those two would be snapshots of about the same time. Updating x264 and leaving MPlayer behind would probably end up with roblems on runtime." If you take a look into their configure script (http://svn.mplayerhq.hu/mplayer/trunk/configure?view=co), you can see something like this http://pastebin.ca/1029547. They search for the value of X264_BUILD in /usr/include/x264.h(greater than 53), which in my x264 update is '#define X264_BUILD 59", so i don't see any problem here. And finally, look the version of ffmpeg in gentoo and arch: http://www.gentoo-portage.com/AJAX/Ebuild/63099 (svn revision 11878 - fmpeg-0.4.9_p20080326.ebuild) http://aur.archlinux.org/packages/ffmpeg-svn/ffmpeg-svn/PKGBUILD (svn revision 13107) Both are updated, in *this* year :) Ok, anyway, i'm not saying your ideas are wrong, i understand them but at this moment i think we can make the updates without any problem, until the next slackware release. BTW, i have execute this command to see wich could be the other apps that should take care of this update(/var/cache/slackbuilds/ is were i sync SBo repository): find /var/cache/slackbuilds/ -name "README" -exec grep ffmpeg {} \; -exec echo -e "{}\n" \; As i can see, they are: kino, transcode, ffmpegthumbnailer and motion, (MOC too) Can another SBo admin/user give an opinion about this topic? that would be nice, i don't want to get a date with Heinz Wiesinger at the end of all this threat hahahaha :) 2008/5/23, Heinz Wiesinger <[EMAIL PROTECTED]>: > Am Freitag, 23. Mai 2008 02:36:39 schrieb Antonio Hernández Blas: > > > Hi all. > > > > I'm the MAINTAINER of ffmpeg and want to announce a new SlackBuild for > > ffmpeg(version 20080521), you can find it at: > > http://hba.nonlogic.org/projects/slackbuilds/testing/ffmpeg-20080521/ > > > > Please, read this before you screw your system ;) > > http://hba.nonlogic.org/projects/slackbuilds/testing/README.WARNING > > > > The main reason to make this announce is to request for persons that > > can/want to test it before i upload it into pending/. Please, take a > > look to > > http://hba.nonlogic.org/projects/slackbuilds/testing/ffmpeg-20080521/README > > to know the changes i've made. > > > > Also, i've updated x264(version 20080521 too): > > http://hba.nonlogic.org/projects/slackbuilds/testing/x264-20080521/ > > I tested ffmpeg with the current SlackBuild in SBo and this update too > > without any problem. > > > > This is actually rather cool ;) > I thought about that too packages a lot in the last few weeks, so now's > probably the right time to share my thoughts. > > Both apps are rather critical, as they do not release tarballs and there are > still many apps depending on them. Making sure everything does *work*, is not > easy, as every app using ffmpeg or x264 has to be tested. > > From my point of view, those two should not be updated that often. I first > thought about an update right after the release of a new Slackware-version, > but I think coordinating those updates with MPlayer-releases would be much > better. There are a few reasons for that. > > MPlayer has a similar development philosophy as ffmpeg (as those are > affiliated), but at least it gets released sometimes. As MPlayer is using > ffmpeg internally we can probably state that the version used by MPlayer is > pretty stable. > MPlayer is also adjusting the interface to x264 in svn, which means that the > perfect combination of those two would be snapshots of about the same time. > Updating x264 and leaving MPlayer behind would probably end up with problems > on runtime. > > Based on that versions we can than start syncing the other apps using them, > which I am not sure about how many there are currently. Anyway, this will be > a huge effort and in no way be a one-an job, as there are just too many deps > to be looked through. > > On a sidenote, I had a look at your README Antonio and want to inform you, > that libamr-nb/wb ARE in the repo. You can find them in audio as amrnb/amrwb. > > My two cents :) > > Grs, > Heinz > _______________________________________________ > SlackBuilds-users mailing list > [email protected] > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > _______________________________________________ SlackBuilds-users mailing list [email protected] http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
