Re: reccomendations of conference / party audio video software ?
Hi, Sorry to arrive late, I just see this post now. If your install videoconferencing software on your machine, you have no guarantee your contacts will be able to use the same, or that they'll know how to install it, or even that they'll be allowed to install anything on their PC. A much easier solution is to use a server based software. You can use a Jitsi-derived solution - a public server is available at https://meet.jit.si/. No account creation needed, no administration, just share a URL and you're done. You can also deploy this solution on one of your servers, it's open source. Another similar solution is BigBlueButton. I'm using it to give trainings, it is simple and efficient. I use it in conjunction with a VM served through Apache Guacamole for the labs. The thing is: your contacts don't need to install anything on their machines (= you don't have to do troubleshooting over the phone), all they need is an HTML5 capable browser. And unlike Skype, the quality of sound and video is good and you don't have to register at Microsoft. Be it meet.jit.si or BigBlueButton, no ports are available yet, but the need for such solutions hasn't been so pressing before. ;) Vincent ___ 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: reccomendations of conference / party audio video software ?
On Mon, 23 Mar 2020 16:15:37 +0100, Vincent DEFERT stated: >And unlike Skype, the quality of sound and video is good and you don't >have to register at Microsoft. I don't believe we even have a version of Skype available for FreeBSD in the ports system. If it is, it is probably well out of date. The latest version of Skype is 8.53.0.77 reported by Microsoft. There are several versions made available by Microsoft for Linux and MAC. Perhaps if enough users flooded Microsoft with a request for a FreeBSD version, it might happen. Personally, I love Skype and have had great success with it. I don't know why you are apparently having audio & video problems. Perhaps it is localized to your equipment. -- Carmel pgp5jOx009YR7.pgp Description: OpenPGP digital signature
Re: users of xorg, in particular on FreeBSD 11.3
In ports r528813 I switched FreeBSD 11 (including FreeBSD 11.3 and the upcoming 11.4) back to use the legacy rule set. This means that once you have installed libxkbcommon 0.10.0_2 on FreeBSD 11, things should work as normal, and the environment variable XKB_DEFAULT_RULES does not need to be changed. If you are on FreeBSD 12 or later, and are using xf96-input-keyboard, you might still need to set this env variable. Please see the instructions below. Regards On 2020-03-21 00:41, Niclas Zeising wrote: [ This is cross-posted across several mailing lists for maximum visibility. Please respect reply-to and keep replies to x...@freebsd.org . Thank you! ] In order to improve support when using evdev to manage input devices, in particular keyboards, we have switched the default in x11/libxkbcommon to the evdev instead of the legacy ruleset. This was done in ports r528813 . On FreeBSD 11.3, the default configuration still requires the legacy ruleset. If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard on FreeBSD 12 or later, you need to change the ruleset used by x11/libxkbcommon. If you have issues with your keyboard, most notably arrow keys, and if /var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being used, you need to switch to legacy rules by setting the environment variable XKB_DEFAULT_RULES to xorg. The easiest way to accomplish this is by adding it to your shell startup file. As an example, for users of [t]csh, put setenv XKB_DEFAULT_RULES xorg in ~/.login For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put export XKB_DEFAULT_RULES=xorg in ~/.profile Regards -- Niclas Zeising FreeBSD Graphics Team ___ 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: users of xorg, in particular on FreeBSD 11.3
On 2020-03-23 22:00, Niclas Zeising wrote: In ports r528813 I switched FreeBSD 11 (including FreeBSD 11.3 and the This should be r529003, sorry about that. upcoming 11.4) back to use the legacy rule set. This means that once you have installed libxkbcommon 0.10.0_2 on FreeBSD 11, things should work as normal, and the environment variable XKB_DEFAULT_RULES does not need to be changed. If you are on FreeBSD 12 or later, and are using xf96-input-keyboard, you might still need to set this env variable. Please see the instructions below. Regards On 2020-03-21 00:41, Niclas Zeising wrote: [ This is cross-posted across several mailing lists for maximum visibility. Please respect reply-to and keep replies to x...@freebsd.org . Thank you! ] In order to improve support when using evdev to manage input devices, in particular keyboards, we have switched the default in x11/libxkbcommon to the evdev instead of the legacy ruleset. This was done in ports r528813 . On FreeBSD 11.3, the default configuration still requires the legacy ruleset. If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard on FreeBSD 12 or later, you need to change the ruleset used by x11/libxkbcommon. If you have issues with your keyboard, most notably arrow keys, and if /var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being used, you need to switch to legacy rules by setting the environment variable XKB_DEFAULT_RULES to xorg. The easiest way to accomplish this is by adding it to your shell startup file. As an example, for users of [t]csh, put setenv XKB_DEFAULT_RULES xorg in ~/.login For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put export XKB_DEFAULT_RULES=xorg in ~/.profile Regards Regards -- Niclas Zeising ___ 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: amd64->armv7 cross-build failure for security/ca_root_nss: It failed in memcpy () from /libexec/ld-elf.so.1
On 2020-Mar-16, at 21:48, Mark Millard wrote:
> Context: head -r358966 attempting to update ports
> to -r528535 . Also, 50+ ports built just fine
> but the below has been repeatable in my context.
>
> The original failure was under devel/poudriere-devel (with
> nxb-bin/ materials used). But part of the below is from
> exploring with various steps in a handier context.
>
> The original error message was:
>
> ===
> ===> Building for ca_root_nss-3.51
> ## Untrusted certificates omitted from this bundle: 2
> openssl x509 failed with exit code 11 at
> /wrkdirs/usr/ports/security/ca_root_nss/work/MAca-bundle.pl line 78.
> *** Error code 255
>
> The original source that reported the message was:
>
> sub printcert_info($$)
> {
>my (undef, $certdata) = @_;
>return unless $certdata;
>open(OUT, "|openssl x509 -text -inform DER -fingerprint")
>|| die "could not pipe to openssl x509";
>print OUT $certdata;
>close(OUT) or die "openssl x509 failed with exit code $?";
> }
>
> The die produced:
>
> -rw-r--r-- 1 root wheel 7909376 Mar 17 03:18:04 2020 qemu_openssl.core
>
> gdb reported for it:
>
> Core was generated by `openssl'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0xf501adb4 in memcpy () from /libexec/ld-elf.so.1
>
> and:
>
> (gdb) info threads
> Id Target Id Frame
> * 1LWP 1592 "x509" 0xf501adb4 in memcpy () from /libexec/ld-elf.so.1
>
> and:
>
> gdb) bt
> #0 0xf501adb4 in memcpy () from /libexec/ld-elf.so.1
> #1 0xf5004cd0 in do_copy_relocations () from /libexec/ld-elf.so.1
>
> and (from a disass):
>
> => 0xf501adb4 <+436>: strdr4, [r3], #8
>
> (It was not clear what code context to supply so
> I stuck to showing the instruction with the register
> used such that SIGSEGV could result from the use: r3 .)
>
> Finally the registers were listed as holding:
>
> (gdb) info reg
> r0 0xf4f5d57c 4109751676
> r1 0x1420
> r2 0x93000 602112
> r3 0x1 1
> r4 0x1016
> r5 0x9fffdfa4 2684346276
> r6 0xf4fe2404 4110296068
> r7 0xf4fe2004 4110295044
> r8 0x93000 602112
> r9 0x93000 602112
> r100x9fffdfe0 2684346336
> r110x0 0
> r120x9fffdf80 2684346240
> sp 0x9fffdf80 0x9fffdf80
> lr 0xf5004cd0 4110437584
> pc 0xf501adb4 0xf501adb4
> cpsr 0x6010 1610612752
>
> Yep: r3==1 would do it.
>
>
> Note: I've otherwise ignored here seeing lots of:
>
> qemu: unsupported syscall: 574 (calling anyway)
>
> notices while doing things for extracting
> this information.
>
>
> I'll note that I had no such SIGSEGV when
> ca_root_nss 3.50 built back at OSVERSION=1300077
> on 2020-Feb-16: it built and worked fine back
> then.
>
>
>
> I'm not sure when I'll have time to do more with this
> or if I will again just abandon qemu-user-static for
> a time. (Insufficient time to allocate to do more?)
> Hopefully the basic information is useful to someone
> at some point.
>
> I'm not claiming that I know qemu-user-static is the
> problem, or openssl, or whatever. Just that the
> combination is broken in my context.
>
> Having security/ca_root_nss blocked, blocks
> cross-building lots of other things, including
> devel/llvm10 .
Using:
# poudriere bulk -j FBSDFSSDjailArmV7 -i -w ports-mgmt/portmaster
to allow trying things from inside the poudriere
build environment, I tried:
# openssl
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
# file `which openssl`
/usr/bin/openssl: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD),
dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0
(1300084), FreeBSD-style, not stripped
The backtrace was again memcpy and do_copy_relocations.
(So "x509" had nothing to do with the inability to
run the original failed command.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
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 +-+ audio/mythplugin-mythmusic | 30.0| v31.0 +-+ multimedia/mythtv | 30.0| v31.0 +-+ multimedia/mythtv-frontend | 30.0| v31.0 +-+ www/mythplugin-mythweb | 29.1| v31.0 +-+ www/xoops | 2.5.8 | 2.5.10 +-+ 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 Reported by:portscout! ___ 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"
