Re: ffmpeg port
Hi! > Le 12/07/2019 à 01:17, Adam Weinberger a écrit : > > We really would love to be able to provide release or LTS branches, > > but it simply comes down to resources. We'd need a few people working > > in paid positions to manage RE environments. The FreeBSD Foundation > > (which underwrites a couple very selective paid positions) has > > prioritized development of new technologies to keep FreeBSD > > competitive over third-party software backporting. > I'm not sure how can a LTS branch that you usually never update (except > CVE, security fixes) take more time than quarterly branches that you need > to recreate every 3 months and do some merges. > Basically, a LTS branch stay in marble for a release lifetime and will > only contain sporadic commits for security fixes or vulnerabilities. The problem are the merges. If you merge a fix to ports HEAD, that same fix normally can not be applied to a LTS version, because HEAD the LTS diverge fast enough to cause trouble. Maintainers and committers in the general case do not provide two patches. Right now, 12.0, 11.3 and 11.2 are still supported. So a maintainer or committer would even need to provide four patches. This is too taxing right now. -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ffmpeg port
Hi! > Am 12.07.2019 um 10:34 schrieb David Demelier : > I'm not sure how can a LTS branch that you usually never update (except CVE, > security fixes) take more time than quarterly branches that you need to > recreate every 3 months and do some merges. The problem is that you need to backport security patches that you don’t get from upstream. E.g. for PHP 5.6. As far as the PHP project is concerned the bugfix for PHP 5.6 is PHP 7.x and PHP 5.6 is dead. If you create an LTS branch with that older version there is the implicit promise that it will be maintained. Redhat does this. I don’t know how large their department for backporting is but i guess it is „huge“. Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ffmpeg port
Le 12/07/2019 à 01:17, Adam Weinberger a écrit : We really would love to be able to provide release or LTS branches, but it simply comes down to resources. We'd need a few people working in paid positions to manage RE environments. The FreeBSD Foundation (which underwrites a couple very selective paid positions) has prioritized development of new technologies to keep FreeBSD competitive over third-party software backporting. Hello Adam, I'm not sure how can a LTS branch that you usually never update (except CVE, security fixes) take more time than quarterly branches that you need to recreate every 3 months and do some merges. Basically, a LTS branch stay in marble for a release lifetime and will only contain sporadic commits for security fixes or vulnerabilities. That's mostly what Slackware does for a release version. For someone who wants bleeding edge, they use slackware-current. Regards, -- David ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ffmpeg port
On Thu, Jul 11, 2019 at 7:18 AM David Demelier wrote: > > Le 10/07/2019 à 13:59, Jan Beich a écrit : > > Why not use binary packages? Or why not build a quarterly branch? > > Or does anyone have better ideas? > > Unfortunately quarterly branches do not solve anything. They are just to > short to have any benefit. Let say you build a package in January and > then you don't touch your system for a while. In September, you realize > you need another port but your local ports also have vulnerabilities. > Now you have to update by changing the quarterly branch since others are > no longer maintained. Then, you may have some local ports that will be > upgraded to a major version which can be undesired for a production > server. This happened to me a while ago when I had to run an old version > of nodejs for an old version of etherpad, after an upgrade the new > nodejs version was no longer compatible and I needed to install node6 > port quickly (hopefully it was available !). > > This can be very frustrating since FreeBSD is a rock solid server OS > that comes with strong compatibility conventions in releases versions > but provides a ports tree in a rolling release fashion that do not match > the base version (unlike OpenBSD does). Then you have to carefully check > each time you need to update your ports that you won't break your system > (like many do with Arch, Gentoo, etc). IMHO, FreeBSD definitely requires > a per-RELEASE branches of ports that contain only bugfixes/security fixes. Hi David, This is a concept that we grapple with continuously, both here and on internal lists. The fact of the matter is that we simply don't have the personpower to maintain more than two concurrent branches (and, by some estimation, more than one). We made the decision a long time ago (whether intentional or de facto) that the best way to ensure consistency was to provide one branch where ports were always kept up-to-date. There is no denying that this underserves environments where stasis is paramount, but it provides the greatest benefit to the greatest number of users. There are ideas being worked on that would improve CI to bring a greater degree of stability to head, but would not directly benefit the deployment scenario you're describing. We really would love to be able to provide release or LTS branches, but it simply comes down to resources. We'd need a few people working in paid positions to manage RE environments. The FreeBSD Foundation (which underwrites a couple very selective paid positions) has prioritized development of new technologies to keep FreeBSD competitive over third-party software backporting. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ffmpeg port
Le 10/07/2019 à 13:59, Jan Beich a écrit : Why not use binary packages? Or why not build a quarterly branch? Or does anyone have better ideas? Unfortunately quarterly branches do not solve anything. They are just to short to have any benefit. Let say you build a package in January and then you don't touch your system for a while. In September, you realize you need another port but your local ports also have vulnerabilities. Now you have to update by changing the quarterly branch since others are no longer maintained. Then, you may have some local ports that will be upgraded to a major version which can be undesired for a production server. This happened to me a while ago when I had to run an old version of nodejs for an old version of etherpad, after an upgrade the new nodejs version was no longer compatible and I needed to install node6 port quickly (hopefully it was available !). This can be very frustrating since FreeBSD is a rock solid server OS that comes with strong compatibility conventions in releases versions but provides a ports tree in a rolling release fashion that do not match the base version (unlike OpenBSD does). Then you have to carefully check each time you need to update your ports that you won't break your system (like many do with Arch, Gentoo, etc). IMHO, FreeBSD definitely requires a per-RELEASE branches of ports that contain only bugfixes/security fixes. -- David ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ffmpeg port
On Thu, 11 Jul 2019 at 00:01, Jan Beich wrote: > > (CC'ing appropriate public list. If you want me to care don't send private > mails.) > > Jason de Cordoba writes: > > > OMG > > > > Please stick with something stable and don't update this port 5-6 times > > a month. > > > > Thanks for your contributions to FreeBSD > > > > Have a great day, > > > > Jason > > I mainly bump PORTREVISION when ABI changes. Bumping for non-default > options is a policy described in Porter's Handbook. > > https://www.freebsd.org/doc/en/books/porters-handbook/makefile-naming.html#makefile-portrevision You should be praised for doing the _right_ thing, instead of being criticized. It's up to each port-user as to whether they want to update their pkgs or not. The only expectation most users have is that it should _work_, build times are irrelevant. My 2 cents. -- Jonathan Chen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ffmpeg port
(CC'ing appropriate public list. If you want me to care don't send private mails.) Jason de Cordoba writes: > OMG > > Please stick with something stable and don't update this port 5-6 times > a month. > > Thanks for your contributions to FreeBSD > > Have a great day, > > Jason I mainly bump PORTREVISION when ABI changes. Bumping for non-default options is a policy described in Porter's Handbook. https://www.freebsd.org/doc/en/books/porters-handbook/makefile-naming.html#makefile-portrevision Why not use binary packages? Or why not build a quarterly branch? Or does anyone have better ideas? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FFMpeg port video4linux
I'm at a loss here; I could be tired, but I cant find if video4linux has been enabled in ffmpeg (or disabled). There's nothing in the makefile either. For the life of me I cannot get it use a webcamd device - all I get is unknown input format. I'm using ffplay (not that should make a difference here), and this is the cmd: $ffplay -f video4linux2 /dev/video0 Just video4linux fails similarly. I was trying to get something to work, and I think I just figured out the why. Can anyone point me to how to get this to work? Or why it doesn't? What do I need to do to make this happen? Cheers ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FFMpeg port video4linux
On 03/24/12 23:31, David Wolfskill wrote: On Sat, Mar 24, 2012 at 11:12:50PM +1000, R Skinner wrote: I'm at a loss here; I could be tired, but I cant find if video4linux has been enabled in ffmpeg (or disabled). There's nothing in the makefile either. For the life of me I cannot get it use a webcamd device - all I get is unknown input format. I'm using ffplay (not that should make a difference here), and this is the cmd: $ffplay -f video4linux2 /dev/video0 Just video4linux fails similarly. ... Can anyone point me to how to get this to work? Or why it doesn't? What do I need to do to make this happen? This may be a usefule clue: g1-227(9.0-S)[1] cd /usr/ports/multimedia/ g1-227(9.0-S)[2] make search key=video4linux Port: libv4l-0.8.4_1 Path: /usr/ports/multimedia/libv4l Info: Video4Linux library Maint: hsela...@freebsd.org B-deps: gettext-0.18.1.1 gmake-3.82 jpeg-8_3 libiconv-1.13.1_2 v4l_compat-1.0.20110720 R-deps: jpeg-8_3 WWW:http://freshmeat.net/projects/libv4l Port: linux-f10-libv4l-0.6.2 Path: /usr/ports/multimedia/linux-f10-libv4l Info: Collection of video4linux support libraries (Fedora 10) Maint: emulat...@freebsd.org B-deps: R-deps: linux_base-f10-10_4 WWW:http://hansdegoede.livejournal.com/3636.html Port: pwcview-1.4.1_4 Path: /usr/ports/multimedia/pwcview Info: The Video4Linux PWC webcam viewer Maint: hsela...@freebsd.org B-deps: aalib-1.4.r5_6 damageproto-1.2.1 dri2proto-2.3 expat-2.0.1_2 fixesproto-5.0 jpeg-8_3 kbproto-1.0.5 libGL-7.4.4 libGLU-7.4.4 libX11-1.4.4,1 libXau-1.0.6 libXdamage-1.1.3 libXdmcp-1.1.0 libXext-1.3.0_1,1 libXfixes-5.0 libXrandr-1.3.2 libXrender-0.9.6 libXxf86vm-1.1.1 libdrm-2.4.12_1 libiconv-1.13.1_2 libpthread-stubs-0.3_3 libv4l-0.8.4_1 libxcb-1.7 pkg-config-0.25_1 randrproto-1.3.2 renderproto-0.11.1 sdl-1.2.15,2 v4l_compat-1.0.20110720 xextproto-7.2.0 xf86vidmodeproto-2.3.1 xproto-7.0.22 R-deps: aalib-1.4.r5_6 damageproto-1.2.1 dri2proto-2.3 expat-2.0.1_2 fixesproto-5.0 jpeg-8_3 kbproto-1.0.5 libGL-7.4.4 libGLU-7.4.4 libX11-1.4.4,1 libXau-1.0.6 libXdamage-1.1.3 libXdmcp-1.1.0 libXext-1.3.0_1,1 libXfixes-5.0 libXrandr-1.3.2 libXrender-0.9.6 libXxf86vm-1.1.1 libdrm-2.4.12_1 libiconv-1.13.1_2 libpthread-stubs-0.3_3 libv4l-0.8.4_1 libxcb-1.7 pkg-config-0.25_1 randrproto-1.3.2 renderproto-0.11.1 sdl-1.2.15,2 xextproto-7.2.0 xf86vidmodeproto-2.3.1 xproto-7.0.22 WWW:http://raaf.atspace.org/ Port: v4l-utils-0.8.4 Path: /usr/ports/multimedia/v4l-utils Info: Video4Linux utilities Maint: n...@freebsd.org B-deps: argp-standalone-1.3_2 gettext-0.18.1.1 gmake-3.82 jpeg-8_3 libiconv-1.13.1_2 libv4l-0.8.4_1 v4l_compat-1.0.20110720 R-deps: argp-standalone-1.3_2 jpeg-8_3 libv4l-0.8.4_1 WWW:http://freshmeat.net/projects/libv4l Port: v4l_compat-1.0.20110720 Path: /usr/ports/multimedia/v4l_compat Info: Video4Linux IOCTL header files Maint: multime...@freebsd.org B-deps: R-deps: WWW: g1-227(9.0-S)[3] I appreciate that, but if it was that simple I would not have asked. I have both libv4l and v4l_compat installed already, but if not then ffmpeg should have installed them anyway. This lies in the ffmpeg build somewhere; it should be automatically enabled but somehow it is missed... There is no --enable-indev in the configure script, just disable. So where else should I be looking? Why would it be disabled (not in the Makefile BTW)? Cheers ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
