Re: coreutils missing one component: (g)stat
> > Now I see where GNU stat is, and it's not FreeBSD's fault that ptxdist > > configure script can't find things. I made a symbolic link in nonroot > > ~/fb64/bin: > > ln -s /usr/local/bin/gnustat gstat > I'm not clear whether you're trying to construct a port, or just > getting the software to build. > If you're building a port, you can achieve that with: > BINARY_ALIAS= gstat=gnustat # Adam - Adam Weinberger I was just trying to get the software to build, or should I say configure. Ptxdist (www.ptxdist.org) has a difficult time finding things: may be buggy. Can FreeBSD ports be updated on a system whose last update was in late July 2017 (11.1-STABLE)? I was able to build FreeBSD 12.0-STABLE and HEAD more recently (May 2019), but the installation was unstable and unable to connect to the internet. But I still get efibootmgr. Tom ___ 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: Improvement to port games/ioquake3
Hi! > I have modified the master port so it now builds and installs an rc script > to launch when configured to build the server. In addition, there is a > sample .cfg file to start a LAN server which can be modified by the end > user, but provides a sane starting point for running the game. > > I think this port has no maintainer so I have no idea who to ping to have > this committed :) Most important is to upload the patch to bugs.freebsd.org so that it does not get lost in the mail flood 8-} Please post the PR# here, I can work on it. -- 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"
Improvement to port games/ioquake3
The port games/ioquake3-server can be used to build a dedicated server for Quake 3 and derivative games. However, it doesn't come with an rc script to launch at system boot or on demand. This makes it a bit tricky to run the dedicated server. This port is a "slave port" that depends on the master port games/ioquake to actually retrieve the source and build everything. I have modified the master port so it now builds and installs an rc script to launch when configured to build the server. In addition, there is a sample .cfg file to start a LAN server which can be modified by the end user, but provides a sane starting point for running the game. I think this port has no maintainer so I have no idea who to ping to have this committed :) games_ioquake3.patch Description: Binary data ___ 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: coreutils missing one component: (g)stat
On Thu, Jul 11, 2019 at 3:26 PM Thomas Mueller wrote: > > from Kurt Jaeger and my previous post: > > > > I noticed, trying to configure ptxdist under FreeBSD (ptxdist.org), that > > > stat (gstat) was missing in sysutils/coreutils. > > > > Configure script execution ended with > > > > checking for GNU rm... /usr/local/bin/grm > > > checking for GNU rmdir... /usr/local/bin/grmdir > > > checking for GNU sort... /usr/local/bin/gsort > > > checking for GNU stat... configure: error: could not find GNU stat > > > Because FreeBSD has its own gstat command (doing something different), > > the port has gnustat for GNU stat. So the configure script > > needs to check for gnustat, maybe this solves your problem? > > Now I see where GNU stat is, and it's not FreeBSD's fault that ptxdist > configure script can't find things. I made a symbolic link in nonroot > ~/fb64/bin: > > ln -s /usr/local/bin/gnustat gstat I'm not clear whether you're trying to construct a port, or just getting the software to build. If you're building a port, you can achieve that with: BINARY_ALIAS= gstat=gnustat # 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: raspberrypi-userland conflicts with mesa-libs
Tracked in bug 225053. After r495793 at least multimedia/omxplayer builds fine[1] on the package cluster. It is not about building omxplayer. It is about raspberrypi-userland been installed in LOCALBASE, conflicting with libEGL from mesa, so you can not install any port using raspberrypi-userland along with mesa-libs. I'm been using FreeBSD just for a few days. I don't think I'm the appropiate person to choose a new prefix for a port. ___ 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: raspberrypi-userland conflicts with mesa-libs
adr writes: > First of all, hello to everyone. > > I'm new to FreeBSD (not to BSD), so pardon me if I look > disoriented. > > Making the userland conflict with mesa-libs is like shooting > in your own foot in this platform. Tracked in bug 225053. After r495793 at least multimedia/omxplayer builds fine[1] on the package cluster. [1] http://beefy8.nyi.freebsd.org/data/head-armv6-default/p505658_s349589/logs/omxplayer-20161004_12.log http://www.ipv6proxy.net/go.php?u=http://beefy16.nyi.freebsd.org/data/head-armv7-default/p506094_s349794/logs/omxplayer-20161004_12.log > Also, I've seen qt5-webengine as a binary package. If I remember > right, it uses gstreamer, and gstreamer also has an omx plugin. > I'll try to code a simple browser. qt5-webengine is broken on armv6 but not armv7. Tracked in bug 238701. Patches welcome in either case. I (a volunteer) don't have any arm* hardware to have an interest in improving the statu quo. ___ 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: raspberrypi-userland conflicts with mesa-libs
On 7/11/19 3:08 PM, adr wrote: First of all, hello to everyone. I'm new to FreeBSD (not to BSD), so pardon me if I look disoriented. Making the userland conflict with mesa-libs is like shooting in your own foot in this platform. I'm a little confused. what specific conflict are you seeing with mesa-libs? -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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"
raspberrypi-userland conflicts with mesa-libs
First of all, hello to everyone. I'm new to FreeBSD (not to BSD), so pardon me if I look disoriented. Making the userland conflict with mesa-libs is like shooting in your own foot in this platform. Omxplayer is a good media player, I modified those ports to be able to be installed in an X environment, and it works really good. The only bug I've seen is the osd been out of place. Also you are not installing dbuscontrol.sh. This is a good example of how to control omxplayer with dbus. I use it directly with key bindings, in my case with twm (I just changed the name to omxctrl): "h" = m4|s : all : ! "omxctrl hidevideo &" "u" = m4|s : all : ! "omxctrl unhidevideo &" "s" = m4|s : all : ! "omxctrl togglesubtitles &" "1" = m4|s : all : ! "omxctrl setvideopos 0 0 600 400; omxctrl setaspectmode letterbox &" "f" = m4|s : all : ! "omxctrl setvideopos 0 0 1920 1080; omxctrl setaspectmode letterbox &" "equal" = m4|s : all : ! "omxctrl volumeup &" "minus" = m4|s : all : ! "omxctrl volumedown &" "q" = m4|s : all : ! "omxctrl stop &" "Space" = m4|s : all : ! "omxctrl pause &" "p" = m4 : all : ! "sh -c 'omxplayer $(youtube-dl --no-playlist -g -f mp4 $(xsel -p))' &" ... you have an idea. Indeed there are a lot of software that support the rpi hardware. Vlc has even a new "split" rpi driver that integrates the player perfectly with the X environment keeping the hardware acceleration. I don't really like this player, but it is the best integrated with X, and is very popular. I'll try to compile it with rpi support on FreeBSD. Also, I've seen qt5-webengine as a binary package. If I remember right, it uses gstreamer, and gstreamer also has an omx plugin. I'll try to code a simple browser. ffmpeg, xine, ... as I said, you are shooting your own foot. Just peek a new prefix, update these ports to use it and add the path to libconfig or just print a message advising the use of LD_LIBRARY_PATH. Just an advise. Regards, adr. ___ 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: coreutils missing one component: (g)stat
from Kurt Jaeger and my previous post: > > I noticed, trying to configure ptxdist under FreeBSD (ptxdist.org), that > > stat (gstat) was missing in sysutils/coreutils. > > Configure script execution ended with > > checking for GNU rm... /usr/local/bin/grm > > checking for GNU rmdir... /usr/local/bin/grmdir > > checking for GNU sort... /usr/local/bin/gsort > > checking for GNU stat... configure: error: could not find GNU stat > Because FreeBSD has its own gstat command (doing something different), > the port has gnustat for GNU stat. So the configure script > needs to check for gnustat, maybe this solves your problem? Now I see where GNU stat is, and it's not FreeBSD's fault that ptxdist configure script can't find things. I made a symbolic link in nonroot ~/fb64/bin: ln -s /usr/local/bin/gnustat gstat That worked so far, but then ptxdist configure script failed on not finding GNU tar (in archivers as gtar, not sysutils/coreutils). I didn't know I needed that! Anyway, thanks for pointing out where GNU stat is. Tom ___ 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: coreutils missing one component: (g)stat
Hi! > I noticed, trying to configure ptxdist under FreeBSD (ptxdist.org), that stat > (gstat) was missing in sysutils/coreutils. > > Configure script execution ended with > > checking for GNU rm... /usr/local/bin/grm > checking for GNU rmdir... /usr/local/bin/grmdir > checking for GNU sort... /usr/local/bin/gsort > checking for GNU stat... configure: error: could not find GNU stat Because FreeBSD has its own gstat command (doing something different), the port has gnustat for GNU stat. So the configure script needs to check for gnustat, maybe this solves your problem? -- 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
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"
coreutils missing one component: (g)stat
I noticed, trying to configure ptxdist under FreeBSD (ptxdist.org), that stat (gstat) was missing in sysutils/coreutils. Configure script execution ended with checking for GNU rm... /usr/local/bin/grm checking for GNU rmdir... /usr/local/bin/grmdir checking for GNU sort... /usr/local/bin/gsort checking for GNU stat... configure: error: could not find GNU stat While I don't expect any FreeBSD list to support ptxdist (or buildroot, openwrt, crosstool-ng), I looked and noticed that gstat was included in sysutils/coreutils in (NetBSD) pkgsrc and sys-apps/coreutils in Haikuports. Haikuports is modeled after Gentoo portage but is much smaller, is the package/ports system used with Haiku. I don't know if ptxdist would have configured and installed with coreutils/gstat, very likely not, and I don't expect support here. My purpose here is to point out something missing in a FreeBSD port. Tom ___ 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"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ lang/adacontrol | 1.18r9 | 1.21r3 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ 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"
