[Bug 199703] [revive port] multimedia/tovid A suite of tools for creating video DVDs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199703 Johannes Jost Meixner x...@freebsd.org changed: What|Removed |Added Assignee|x...@freebsd.org |freebsd-ports@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ 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
[Bug 187884] [PATCH] science/minc2: update to 2.2.00
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187884 Johannes Jost Meixner x...@freebsd.org changed: What|Removed |Added Assignee|x...@freebsd.org |freebsd-ports@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ 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
[Bug 193798] net-im/skype obsolete version, but problem on upgrade to newer
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193798 Johannes Jost Meixner x...@freebsd.org changed: What|Removed |Added Assignee|x...@freebsd.org |freebsd-ports@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ 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
[Bug 199703] [revive port] multimedia/tovid A suite of tools for creating video DVDs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199703 Kubilay Kocak ko...@freebsd.org changed: What|Removed |Added Keywords||needs-qa, patch Assignee|freebsd-ports@FreeBSD.org |ko...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ 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
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 +-+ print/lilypond-devel| 2.19.11 | 2.19.22 +-+ 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 http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
links port Makefile logic error
___ 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
www/squid: tcp_outgoing_address binds to wrong interface
Hello, I am experiencing an issue with squid 3.5.5 and FreeBSD 10.1 where tcp_outgoing_address correctly rewrites the source address of outgoing packets, but fails to bind the socket to the correct interface. I've been using this kind of setup/configuration for quite some time (since the squid 2.7 days), so I believe something between FreeBSD 9.x and 10.1 has broken this behavior. FWIW squid 3.3.3 on FreeBSD 9.x behaves correctly with the same config. My understanding is that squid merely changes the source address as a hint to the kernel routing stack, which makes me believe the problem lies outside of squid. I've already sought out help from the squid-users mailing list and been told the same thing. I've been able to replicate this on a non-production VM with a simple config. For example, I have two WAN interfaces: WAN1 (em0/192.168.92.246) and WAN2 (em1/10.8.8.10), and a LAN interface (em2/192.168.5.1/24). My default route points to the gateway for WAN1/em0. I have configured a tcp_outgoing_address for a single host on the LAN (192.168.5.2) to use outgoing address 10.8.8.10 (WAN2/em1). HTTP request packets from squid end up going out em0 (the default route interface) with an ip of 10.8.8.10. The source IP is correct but the packets egress the wrong interface, so they are obviously dropped by the upstream router on that incorrect interface. This is evident by tcpdump on em0. The following is my test squid.conf and some basic network config. While I normally use squid as a transparent proxy in conjunction with PF+ALTQ for NAT/firewall and routing enabled, for the purposes of replicating the issue in my VM test environment I have disabled PF, routing, and connected directly to squid via my browser's proxy config. Attempts to load webpages time out unless I remove use of the tcp_outgoing_address directive. # begin test squid.conf acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow localhost manager http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow all acl wan2 src 192.168.5.2 tcp_outgoing_address 10.8.8.10 wan2 follow_x_forwarded_for allow localhost acl_uses_indirect_client on log_uses_indirect_client on http_port 3129 cache_replacement_policy heap LFUDA maximum_object_size 768 MB cache_dir aufs /squid/cache 2048 32 512 access_log daemon:/squid/logs/access.log squid cache_log /squid/logs/cache.log cache_store_log none logfile_rotate 0 pid_filename /var/run/squid.pid # end test squid.conf em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:0c:29:a3:33:93 inet 192.168.92.246 netmask 0xff00 broadcast 192.168.92.255 nd6 options=9PERFORMNUD,IFDISABLED media: Ethernet autoselect (1000baseT full-duplex) status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:0c:29:a3:33:7f inet 10.8.8.10 netmask 0xff00 broadcast 10.8.8.255 inet 10.8.8.11 netmask 0xff00 broadcast 10.8.8.255 inet 10.8.8.12 netmask 0xff00 broadcast 10.8.8.255 inet 10.8.8.13 netmask 0xff00 broadcast 10.8.8.255 inet 10.8.8.14 netmask 0xff00 broadcast 10.8.8.255 nd6 options=9PERFORMNUD,IFDISABLED media: Ethernet autoselect (1000baseT full-duplex) status: active root# netstat -rn | grep default default192.168.92.2 UGS em0 I am hoping someone can shed some light on this issue. Thank you. -Nick ___ 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: www/squid: tcp_outgoing_address binds to wrong interface
On 30 Jun 2015, at 18:48, Nick Rogers ncrog...@gmail.com wrote: ... I am experiencing an issue with squid 3.5.5 and FreeBSD 10.1 where tcp_outgoing_address correctly rewrites the source address of outgoing packets, but fails to bind the socket to the correct interface. How do you arrive at this conclusion? In the rest of your mail I see no squid configuration for this, e.g. you would have to use: http_port 10.8.8.10:3129 to explicitly bind to the first address on em1. You can add multiple http_port settings to bind to multiple addresses. I've been using this kind of setup/configuration for quite some time (since the squid 2.7 days), so I believe something between FreeBSD 9.x and 10.1 has broken this behavior. FWIW squid 3.3.3 on FreeBSD 9.x behaves correctly with the same config. My understanding is that squid merely changes the source address as a hint to the kernel routing stack, which makes me believe the problem lies outside of squid. I've already sought out help from the squid-users mailing list and been told the same thing. ... root# netstat -rn | grep default default192.168.92.2 UGS em0 Do you have a route for 10.8.8.10 and similar? Those should point to em1, obviously. If there is no specific route, those packets will simply go to the default gateway. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: www/squid: tcp_outgoing_address binds to wrong interface
On Tue, Jun 30, 2015 at 11:54 AM, Dimitry Andric d...@freebsd.org wrote: On 30 Jun 2015, at 18:48, Nick Rogers ncrog...@gmail.com wrote: ... I am experiencing an issue with squid 3.5.5 and FreeBSD 10.1 where tcp_outgoing_address correctly rewrites the source address of outgoing packets, but fails to bind the socket to the correct interface. How do you arrive at this conclusion? In the rest of your mail I see no squid configuration for this, e.g. you would have to use: http_port 10.8.8.10:3129 to explicitly bind to the first address on em1. You can add multiple http_port settings to bind to multiple addresses. The http_port directive is for the address/port squid listens on for incoming client connections to the proxy, not what it uses to initiate outbound HTTP connections. The tcp_outgoing_address directive is what controls the source IP of outbound requests to web servers. I've been using this kind of setup/configuration for quite some time (since the squid 2.7 days), so I believe something between FreeBSD 9.x and 10.1 has broken this behavior. FWIW squid 3.3.3 on FreeBSD 9.x behaves correctly with the same config. My understanding is that squid merely changes the source address as a hint to the kernel routing stack, which makes me believe the problem lies outside of squid. I've already sought out help from the squid-users mailing list and been told the same thing. ... root# netstat -rn | grep default default192.168.92.2 UGS em0 Do you have a route for 10.8.8.10 and similar? Those should point to em1, obviously. If there is no specific route, those packets will simply go to the default gateway. 10.8.8.10 is an alias configured on em1. root# ifconfig em1 em1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:0c:29:a3:33:7f inet 10.8.8.10 netmask 0xff00 broadcast 10.8.8.255 nd6 options=9PERFORMNUD,IFDISABLED media: Ethernet autoselect (1000baseT full-duplex) status: active root# netstat -rn | grep em1 10.8.8.0/24link#1 U em1 Is that not sufficient for the kernel to know that packets with a source IP of 10.8.8.10 should egress em1, which has 10.8.8.10 configured via ifconfig? If I using ping -S the packets go out the correct interface (e.g., ping -S 10.8.8.10 10.8.8.250). -Dimitry ___ 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
Cannot Compile Firefox as a PIE
I'm on FreeBSD 11-CURRENT (well, technically, HardenedBSD). I'm trying to compile firefox as a Position-Independent Executable. No matter the approach I take, I get an error. I've filed a bug upstream with Firefox (link below). Is there something else I should be doing? Link to bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1178979 `uname -a`: FreeBSD laptop-dev-01 11.0-CURRENT-HBSD FreeBSD 11.0-CURRENT-HBSD #12 30bd880(hardened/current/master): Tue Jun 23 11:28:31 EDT 2015 shawn@laptop-dev-01:/usr/obj/usr/src/sys/LATT-SEC amd64 Thanks, -- Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: This is a digitally signed message part
Re: www/squid: tcp_outgoing_address binds to wrong interface
On Tue, Jun 30, 2015 at 2:36 PM, Nick Rogers ncrog...@gmail.com wrote: On Tue, Jun 30, 2015 at 11:54 AM, Dimitry Andric d...@freebsd.org wrote: On 30 Jun 2015, at 18:48, Nick Rogers ncrog...@gmail.com wrote: ... I am experiencing an issue with squid 3.5.5 and FreeBSD 10.1 where tcp_outgoing_address correctly rewrites the source address of outgoing packets, but fails to bind the socket to the correct interface. How do you arrive at this conclusion? In the rest of your mail I see no squid configuration for this, e.g. you would have to use: http_port 10.8.8.10:3129 to explicitly bind to the first address on em1. You can add multiple http_port settings to bind to multiple addresses. The http_port directive is for the address/port squid listens on for incoming client connections to the proxy, not what it uses to initiate outbound HTTP connections. The tcp_outgoing_address directive is what controls the source IP of outbound requests to web servers. I've been using this kind of setup/configuration for quite some time (since the squid 2.7 days), so I believe something between FreeBSD 9.x and 10.1 has broken this behavior. FWIW squid 3.3.3 on FreeBSD 9.x behaves correctly with the same config. My understanding is that squid merely changes the source address as a hint to the kernel routing stack, which makes me believe the problem lies outside of squid. I've already sought out help from the squid-users mailing list and been told the same thing. ... root# netstat -rn | grep default default192.168.92.2 UGS em0 Do you have a route for 10.8.8.10 and similar? Those should point to em1, obviously. If there is no specific route, those packets will simply go to the default gateway. 10.8.8.10 is an alias configured on em1. root# ifconfig em1 em1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:0c:29:a3:33:7f inet 10.8.8.10 netmask 0xff00 broadcast 10.8.8.255 nd6 options=9PERFORMNUD,IFDISABLED media: Ethernet autoselect (1000baseT full-duplex) status: active root# netstat -rn | grep em1 10.8.8.0/24link#1 U em1 Is that not sufficient for the kernel to know that packets with a source IP of 10.8.8.10 should egress em1, which has 10.8.8.10 configured via ifconfig? If I using ping -S the packets go out the correct interface (e.g., ping -S 10.8.8.10 10.8.8.250). I believe I understand your point now... There is no way to specify a route based on the source IP of the packet, thus it will always egress the default route interface even though the desired source IP is configured on a different interface. I suppose I can handle the source-based routing with PF. Thank you. -Dimitry ___ 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
