Re: TCL and Unicode
On Mon, Mar 22, 2021 at 06:32:29PM +0100, Dimitry Andric wrote: > On 22 Mar 2021, at 14:40, Shawn Webb wrote: > > > > I'm tracking down a regression in ports regarding TCL and unicode. The > > primary victim of the problem is databases/sqlite3. Note that I use > > freebsd-ports on github as my upstream, so I'll be using git commit > > hashes from that repo. > > > > The sqlite3 build failure can be seen at [1]. > > > > If I revert commit 787aad81fc79d441fb0c9a750e6e33b6c0ea7ac6, sqlite3 > > builds fine. I noticed a few key changes from that commit: > > > > The build of sqlite3 depends on TCL: instead of using the distfile > > that has the autoconf artifacts pre-generated, the distfile without > > the autoconf artifacts is used (changing from > > sqlite-autoconf-3340100.tar.gz to sqlite-src-3340100.zip). This > > means that the TCL-based autoconf artifacts must be generated > > locally. At least, partially. It seems that the only part of the > > build that depends on TCL is the sqlite3_analyzer. > > > > Admittedly, this change is somewhat confusing to me. I'm having > > somewhat of a hard time knowing whether it's TCL or sqlite3 itself > > as the main culprit. > > > > Any guidance is appreciated. > > > > [1]: > > http://ci-08.md.hardenedbsd.org/data/hardenedbsd-current_amd64-local/2021-03-21_13h53m43s/logs/errors/sqlite3-3.34.1,1.log > > Hi Shawn, > > It builds fine for me locally on 14.0-CURRENT (as of ~2 days ago), and > indeed the sqlite3.c file is now dynamically generated by tcl. > > In your CI failure case, it looks like something is inserting blobs of > zero bytes into the resulting file, though? So either the file system > is going bad, or tcl is outputting nonsense, for some reason. At least, > I think you'll have to do some investigations in that direction... Looks like compiling lang/tcl86 with the following CFLAGS causes tcl to output invalid unicode for some reason: -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang Thanks for the hint! -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
TCL and Unicode
Hey all, I'm tracking down a regression in ports regarding TCL and unicode. The primary victim of the problem is databases/sqlite3. Note that I use freebsd-ports on github as my upstream, so I'll be using git commit hashes from that repo. The sqlite3 build failure can be seen at [1]. If I revert commit 787aad81fc79d441fb0c9a750e6e33b6c0ea7ac6, sqlite3 builds fine. I noticed a few key changes from that commit: The build of sqlite3 depends on TCL: instead of using the distfile that has the autoconf artifacts pre-generated, the distfile without the autoconf artifacts is used (changing from sqlite-autoconf-3340100.tar.gz to sqlite-src-3340100.zip). This means that the TCL-based autoconf artifacts must be generated locally. At least, partially. It seems that the only part of the build that depends on TCL is the sqlite3_analyzer. Admittedly, this change is somewhat confusing to me. I'm having somewhat of a hard time knowing whether it's TCL or sqlite3 itself as the main culprit. Any guidance is appreciated. [1]: http://ci-08.md.hardenedbsd.org/data/hardenedbsd-current_amd64-local/2021-03-21_13h53m43s/logs/errors/sqlite3-3.34.1,1.log Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Creating port from pre-built package
On Thu, Feb 11, 2021 at 06:09:52PM +0100, Patrick M. Hausen wrote: > Hi all, > > > Am 11.02.2021 um 18:03 schrieb Chris : > > > > On 2021-02-11 08:26, Shawn Webb wrote: > >> Hey all, > >> The Splunk universal forwarder for FreeBSD is distributed as a package > >> tarball that you can use `pkg add` on. I'm in a position where I'd > >> like to create a port of the package so that I can automate certain > >> tasks. > > Reverse engineer a package? I think that will violate the NDA you > > signed. ;-) > > > > Really. Unless the package is simply a wrapper of a binary blob. You'll > > need to *build* the port, as part of the package creation process. > > That is, unless I've *completely* misunderstood your intent here. :-) > > The binary package is provided by the software manufacturer without > source code. > > Still one might want to have a port available so one can put the port > in poudriere and have it available in one's own package repo. > Right, I'm not aiming to recompile the software. I'm looking to simply create a new package.txz with the pre-built artifacts included. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Creating port from pre-built package
On Thu, Feb 11, 2021 at 09:03:19AM -0800, Chris wrote: > On 2021-02-11 08:26, Shawn Webb wrote: > > Hey all, > > > > The Splunk universal forwarder for FreeBSD is distributed as a package > > tarball that you can use `pkg add` on. I'm in a position where I'd > > like to create a port of the package so that I can automate certain > > tasks. > Reverse engineer a package? I think that will violate the NDA you > signed. ;-) > > Really. Unless the package is simply a wrapper of a binary blob. You'll > need to *build* the port, as part of the package creation process. > That is, unless I've *completely* misunderstood your intent here. :-) It's literally a package of pre-built binaries. You can install it by running: # pkg add ./splunkforwarder-8.0.7-cbe73339abca-freebsd-11.1-amd64.txz Here's what `pkg info` shows: $ pkg info -F splunkforwarder-8.0.7-cbe73339abca-freebsd-11.1-amd64.txz [11:55:13] splunkforwarder-8.0.7 Name : splunkforwarder Version: 8.0.7 Origin : sysutils/splunk Architecture : FreeBSD:11:amd64 Prefix : /opt Categories : Licenses : Maintainer : eng-rele...@splunk.com WWW: http://www.splunk.com Comment: Splunk> The platform for machine data. Annotations: no_provide_shlib: yes FreeBSD_version: 1101001 Flat size : 56.6MiB Description: Splunk> The platform for machine data. (C) 2005-2020 Splunk Inc. All rights Reserved I'm not looking to re-build the binaries, but rather just use ports to recreate the package given a pre-existing package tarball. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Creating port from pre-built package
Hey all, The Splunk universal forwarder for FreeBSD is distributed as a package tarball that you can use `pkg add` on. I'm in a position where I'd like to create a port of the package so that I can automate certain tasks. Being a ports newb, I'm not sure how to properly create a port from a pre-built package. Does anyone have any non-xkcd pointers[1]? [1]: https://xkcd.com/138/ Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: OpenJDK ports and 13-CURRENT
On Sat, Oct 10, 2020 at 09:45:58PM +0200, Dimitry Andric wrote: > On 10 Oct 2020, at 21:23, Shawn Webb wrote: > > > > On Sat, Oct 10, 2020 at 09:18:08PM +0200, Dimitry Andric wrote: > >> On 10 Oct 2020, at 21:03, Shawn Webb wrote: > >>> It appears the latest import of llvm 11.0.0 breaks the OpenJDK 12 and > >>> above ports. Is anyone tracking this breakage? > >> > >> Define "break". :) I can't find any PR, so I don't think so. The latest > >> builds on the ports cluster seem to have succeeded, but even though the > >> ports builder says "head-amd64-default-job", it appears to compile with > >> clang 8.0.1, for some reason. Might be incorrect, or on purpose, I don't > >> know. > > > > Log of the HardenedBSD 13-CURRENT/amd64 package > > build:http://ci-03.md.hardenedbsd.org/data/hardenedbsd-13_amd64-local/2020-10-09_14h46m02s/logs/errors/openjdk12-12.0.2+10.4_1.log > > > > HardenedBSD has switched to a full llvm compiler toolchain. I wonder > > if that's the culprit? Using llvm-ar, llvm-nm, et al. > > > > Googling for the duplicate symbol error brought me this result: > > https://www.mail-archive.com/freebsd-pkg-fallout@freebsd.org/msg1544005.html > > Ah, that is -fno-common fallout, strange that there is no build breakage > reported in the FreeBSD ports build cluster? > > From gcc 10 and clang 11 onwards, -fno-common is the default (this is > really a historical mistake, -fcommon should never have been default). > > It can result in link errors, if duplicate symbols exist in object > files. There is a suprising amount of software that makes this very > basic mistake! > > The quick way to work around these errors is to set -fcommon in CFLAGS, > which will basically fudge around the actual issue. The better way is to > get rid of the duplicated symbols. This is usually easy, except that > Java ports tend to take ages to build. :) I'll submit a patch when my > machine's finished crunching through it. Yup. Another victim: print/tex-luatex: https://git-01.md.hardenedbsd.org/HardenedBSD/hardenedbsd-ports/commit/229b7663bc82ff7e471dc1e19662f68d4226984a -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: OpenJDK ports and 13-CURRENT
On Sat, Oct 10, 2020 at 09:18:08PM +0200, Dimitry Andric wrote: > On 10 Oct 2020, at 21:03, Shawn Webb wrote: > > It appears the latest import of llvm 11.0.0 breaks the OpenJDK 12 and > > above ports. Is anyone tracking this breakage? > > Define "break". :) I can't find any PR, so I don't think so. The latest > builds on the ports cluster seem to have succeeded, but even though the > ports builder says "head-amd64-default-job", it appears to compile with > clang 8.0.1, for some reason. Might be incorrect, or on purpose, I don't > know. Log of the HardenedBSD 13-CURRENT/amd64 package build:http://ci-03.md.hardenedbsd.org/data/hardenedbsd-13_amd64-local/2020-10-09_14h46m02s/logs/errors/openjdk12-12.0.2+10.4_1.log HardenedBSD has switched to a full llvm compiler toolchain. I wonder if that's the culprit? Using llvm-ar, llvm-nm, et al. Googling for the duplicate symbol error brought me this result: https://www.mail-archive.com/freebsd-pkg-fallout@freebsd.org/msg1544005.html Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
OpenJDK ports and 13-CURRENT
Hey all, It appears the latest import of llvm 11.0.0 breaks the OpenJDK 12 and above ports. Is anyone tracking this breakage? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: LibreOffice 6.4.4 is coming!
On Fri, Jun 12, 2020 at 01:10:37AM +1000, Dima Panov wrote: > Discussions, patches, proposals are welcome. > > We're sorry for the inconvenience. Hey Dima, There is nothing inconvenient about enjoying your hard work. You're awesome and your work (along with any other contributors) is very much appreciated. Thank you so much for all you do. -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Retiring GNU objdump 2.17.50
On Thu, Jan 09, 2020 at 10:31:55AM -0500, Ed Maste wrote: > We currently install and use at most three tools from GNU binutils > 2.17.50, depending on target architecture: > > 1. as - assembler > 2. ld - linker > 3. objdump - diagnostic / information tool > > I hope to retire all use of these obsolete binutils before FreeBSD 13. > Here I'd like to discuss objdump. It is a diagnostic tool that > provides information about object files, binaries and libraries. It's > not required as a bootstrap tool (i.e., not needed to build FreeBSD > world or kernel). It is required to build a limited number of ports, > and is used by some developers. > > I have a tracking PR for GNU objdump's retirement open in PR 229046. > https://bugs.freebsd.org/229046. > > There are two ways we can proceed with its retirement: > > 1. Remove it without replacement. Ports that need objdump to build > will have to depend on the binutils package/port, and users who wish > to use it will have to install it. > > Related links for this path: > Ports exp-run: https://bugs.freebsd.org/212319 > Patch review: https://reviews.freebsd.org/D7338 > > 2. Install llvm-objdump in its place (perhaps via a symlink). > llvm-objdump is broadly compatible in both command-line argument > parsing and output format, but there are many small differences and > it's not a full drop-in replacement. > > Related links for this path: > Patch review: https://reviews.freebsd.org/D18307 Hey Ed, In preparation for Cross-DSO CFI, HardenedBSD made the switch to llvm-objdump a long while ago. Therea are, indeed, subtle breakages in ports. Not all options are supported. I added a LLVM_OBJDUMP_UNSAFE flag, and some ports still have trouble with it. Unfortunately, my spare time at this very moment is not large enough to allow me to document HardenedBSD's initial findings with regards to the switch. I wll, however, add that to my todo list. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Port Request: OpenSCAP
I'm not really a compliance guru, so I can't say whether HardenedBSD comes closer to . I have looked into Common Criteria/NIAP briefly for US Federal Government deployments in certain high-security enclaves. HardenedBSD does come closer with CC/NIAP, though there are still gaps to fill. Have you looked at OPNsense? It's a fork of pfSense built on top of HardenedBSD. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE On Tue, Mar 26, 2019 at 05:42:43PM +, Paul Pathiakis wrote: > Sorry for the top-post. > Shawn, > It seems that NIST, FIPS 140-2, and things along those lines are quickly > becoming a complete reality for all people dealing with the US Gov't no > matter what the size company. > So, encryption modules must be FIPs approved for compliance and NIST 800-171 > is the other compliance that is needed. > > I've been tasked with creating an entire, new infrastructure that > meets/complies with those specs.?? So, I dug in a little bit and found SCAP > which lead to OpenSCAP.?? So, I get to put the whole thing behind pfSense > firewalls and show that everything I'm running is compliant with both > standards. > > > Does HardenedBSD meet the requirements? :D?? (crosses fingers) > Paul > > > On Tuesday, March 26, 2019, 1:06:25 PM EDT, Shawn Webb > wrote: > > On Tue, Mar 26, 2019 at 05:02:48PM +, Paul Pathiakis via freebsd-ports > wrote: > > https://www.open-scap.org/ > > > > Hi all, > > > > It's the US NIST scanner for operating system compliance. > > > > I'd like to use FreeBSD and FreeNAS in various places but it has to pass > > compliance. > > I just asked my coworkers about it. They created OpenSCAP. :) > > What compliance requirements are you looking to pass? > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > Tor-ified Signal:?? ?? +1 443-546-8752 > Tor+XMPP+OTR:?? ?? ?? ?? latt...@is.a.hacker.sx > GPG Key ID:?? ?? ?? ?? ?? 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89?? 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: Port Request: OpenSCAP
On Tue, Mar 26, 2019 at 05:02:48PM +, Paul Pathiakis via freebsd-ports wrote: > https://www.open-scap.org/ > > Hi all, > > It's the US NIST scanner for operating system compliance. > > I'd like to use FreeBSD and FreeNAS in various places but it has to pass > compliance. I just asked my coworkers about it. They created OpenSCAP. :) What compliance requirements are you looking to pass? Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: devel/phpunit6@php56 error due to last commit for devel/pear-PEAR_Info
On Wed, Jul 04, 2018 at 03:52:26PM +0200, Ren?? Ladan wrote: > On 04-07-2018 14:54, Shawn Webb wrote: > > It looks like poudriere has issues with the latest commit that touched > > devel/pear-PEAR_Info: > > > > [00:03:53] Error: compute_deps_pkg failed to lookup pkgname for > > devel/phpunit6@php56 processing package php56-pear-PEAR_Info-1.9.2_2 from > > devel/pear-PEAR_Info -- Is SUBDIR+=phpunit6@php56 missing in devel/Makefile > > and does the port provide the 'php56' FLAVOR? > > [00:03:53] Error: compute_deps_pkg failed to lookup pkgname for > > devel/phpunit6@php56 processing package php56-pear-PHP_CompatInfo-1.9.0_4 > > from devel/pear-PHP_CompatInfo -- Is SUBDIR+=phpunit6@php56 missing in > > devel/Makefile and does the port provide the 'php56' FLAVOR? > > > > The commit in question is commit > > bf7e4734b7fededa2e240d1c584365abbd12ac03 in the FreeBSD Ports github > > repo. > > > > This is on 12-CURRENT/amd64. > Fixed in r473885 (the ports will now only be built with PHP 7.0 or later). Awesome. Thanks! -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
devel/phpunit6@php56 error due to last commit for devel/pear-PEAR_Info
It looks like poudriere has issues with the latest commit that touched devel/pear-PEAR_Info: [00:03:53] Error: compute_deps_pkg failed to lookup pkgname for devel/phpunit6@php56 processing package php56-pear-PEAR_Info-1.9.2_2 from devel/pear-PEAR_Info -- Is SUBDIR+=phpunit6@php56 missing in devel/Makefile and does the port provide the 'php56' FLAVOR? [00:03:53] Error: compute_deps_pkg failed to lookup pkgname for devel/phpunit6@php56 processing package php56-pear-PHP_CompatInfo-1.9.0_4 from devel/pear-PHP_CompatInfo -- Is SUBDIR+=phpunit6@php56 missing in devel/Makefile and does the port provide the 'php56' FLAVOR? The commit in question is commit bf7e4734b7fededa2e240d1c584365abbd12ac03 in the FreeBSD Ports github repo. This is on 12-CURRENT/amd64. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: make reinstall does not work
On Fri, Dec 08, 2017 at 10:35:50PM +0100, Walter Schwarzenfeld wrote: > I had a strange error: Make reinstall does not work anymore in the port > (10.3-amd64) also FORCE_PKG_REGISTER. > > All other make commands works fine. I don't know if it is related to > FLAVORS. > > make reinstall ended up e.g. with: > > ??Registering installation for gtk2-2.24.31 > *** Error code 70 > > Stop. > make[2]: stopped in /usr/ports/x11-toolkits/gtk20 > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/x11-toolkits/gtk20 > *** Error code 1 > > Any idea or suggestion? This is due to this commit: https://github.com/freebsd/pkg/commit/7991c49665419916210ad589d4a85fd2a7f58b37 The standard procedure for reinstall is to do a deinstall first. I guess it's pretty common just to issue `make reinstall` (which is what I used to do as well). However, that's not the originally intended behavior as designed in the Ports build framework. So: just do a `make deinstall reinstall`. It'll work that way. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
security/libgcrypt fails to build on arm64
Looks like the patches don't apply. Full log posted here: https://hardenedbsd.org/~shawn/logs/libgcrypt-1.8.0.log Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: 64-bit inodes (ino64) Status Update and Call for Testing
On Mon, May 15, 2017 at 03:41:45PM -0400, Shawn Webb wrote: > On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote: > > Inodes are data structures corresponding to objects in a file system, > > such as files and directories. FreeBSD has historically used 32-bit > > values to identify inodes, which limits file systems to somewhat under > > 2^32 objects. Many modern file systems internally use 64-bit identifiers > > and FreeBSD needs to follow suit to properly and fully support these > > file systems. > > > > The 64-bit inode project, also known as ino64, started life many years > > ago as a project by Gleb Kurtsou (gleb@). After that time several > > people have had a hand in updating it and addressing regressions, after > > mckusick@ picked up and updated the patch, and acted as a flag-waver. > > > > Sponsored by the FreeBSD Foundation I have spent a significant effort > > on outstanding issues and integration -- fixing compat32 ABI, NFS and > > ZFS, addressing ABI compat issues and investigating and fixing ports > > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > > jhb@ provided feedback and review on the ABI transition support. pho@ > > performed extensive testing and identified a number of issues that > > have now been fixed. kris@ performed an initial ports investigation > > followed by an exp-run by antoine@. emaste@ helped with organization > > of the process. > > > > This note explains how to perform useful testing of the ino64 branch, > > beyond typical smoke tests. > > > > 1. Overview. > > > > The ino64 branch extends the basic system types ino_t and dev_t from > > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent > > layout is modified due to the larger size of ino_t, and also gains a > > d_off (directory offset) member. As ino64 implies an ABI change anyway > > the struct statfs f_mntfromname[] and f_mntonname[] array length > > MNAMELEN is increased from 88 to 1024, to allow for longer mount path > > names. > > > > ABI breakage is mitigated by providing compatibility using versioned > > symbols, ingenious use of the existing padding in structures, and by > > employing other tricks. Unfortunately, not everything can be fixed, > > especially outside the base system. For instance, third-party APIs > > which pass struct stat around are broken in backward and forward- > > incompatible way. > > > > 2. Motivation. > > > > The main risk of the ino64 change is the uncontrolled ABI breakage. > > Due to expansion of the basic types dev_t, ino_t and struct dirent, > > the impact is not limited to one part of the system, but affects: > > - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo > > and more) > > - libc interface (mostly related to the readdir(3), FTS(3)) > > - collateral damage in other libraries that happens to use changed types > > in the interfaces. See, for instance, libprocstat, for which compat > > was provided using symbol versioning, and libutil, which shlib version > > was bumped. > > > > 3. Quirks. > > > > We handled kinfo sysctl MIBs, but other MIBs which report structures > > depended on the changed type, are not handled in general. It was > > considered that the breakage is either in the management interfaces, > > where we usually allow ABI slip, or is not important. > > > > Struct xvnode changed layout, no compat shims are provided. > > > > For struct xtty, dev_t tty device member was reduced to uint32_t. It > > was decided that keeping ABI compat in this case is more useful than > > reporting 64bit dev_t, for the sake of pstat. > > > > 4. Testing procedure. > > > > The ino64 project can be tested by cloning the project branch from > > GitHub or by applying the patch > at URL | attached> to a working tree. The authorative source is the > > GitHub, I do not promise to update the review for each update. > > > > To clone from GitHub: > > % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino64 > > > > To fetch the patch from Phabricator: > > - Visit https://reviews.freebsd.org/D10439 > > - Click "Download Raw Diff" at the upper right of the page > > > > Or > > % arc patch D10439 > > > > After that, in the checkout directory do > > % (cd sys/kern && touch syscalls.master && make sysent) > > % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent) > > If you use custom kernel
Re: 64-bit inodes (ino64) Status Update and Call for Testing
On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote: > Inodes are data structures corresponding to objects in a file system, > such as files and directories. FreeBSD has historically used 32-bit > values to identify inodes, which limits file systems to somewhat under > 2^32 objects. Many modern file systems internally use 64-bit identifiers > and FreeBSD needs to follow suit to properly and fully support these > file systems. > > The 64-bit inode project, also known as ino64, started life many years > ago as a project by Gleb Kurtsou (gleb@). After that time several > people have had a hand in updating it and addressing regressions, after > mckusick@ picked up and updated the patch, and acted as a flag-waver. > > Sponsored by the FreeBSD Foundation I have spent a significant effort > on outstanding issues and integration -- fixing compat32 ABI, NFS and > ZFS, addressing ABI compat issues and investigating and fixing ports > failures. rmacklem@ provided feedback on NFS changes, emaste@ and > jhb@ provided feedback and review on the ABI transition support. pho@ > performed extensive testing and identified a number of issues that > have now been fixed. kris@ performed an initial ports investigation > followed by an exp-run by antoine@. emaste@ helped with organization > of the process. > > This note explains how to perform useful testing of the ino64 branch, > beyond typical smoke tests. > > 1. Overview. > > The ino64 branch extends the basic system types ino_t and dev_t from > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent > layout is modified due to the larger size of ino_t, and also gains a > d_off (directory offset) member. As ino64 implies an ABI change anyway > the struct statfs f_mntfromname[] and f_mntonname[] array length > MNAMELEN is increased from 88 to 1024, to allow for longer mount path > names. > > ABI breakage is mitigated by providing compatibility using versioned > symbols, ingenious use of the existing padding in structures, and by > employing other tricks. Unfortunately, not everything can be fixed, > especially outside the base system. For instance, third-party APIs > which pass struct stat around are broken in backward and forward- > incompatible way. > > 2. Motivation. > > The main risk of the ino64 change is the uncontrolled ABI breakage. > Due to expansion of the basic types dev_t, ino_t and struct dirent, > the impact is not limited to one part of the system, but affects: > - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo > and more) > - libc interface (mostly related to the readdir(3), FTS(3)) > - collateral damage in other libraries that happens to use changed types > in the interfaces. See, for instance, libprocstat, for which compat > was provided using symbol versioning, and libutil, which shlib version > was bumped. > > 3. Quirks. > > We handled kinfo sysctl MIBs, but other MIBs which report structures > depended on the changed type, are not handled in general. It was > considered that the breakage is either in the management interfaces, > where we usually allow ABI slip, or is not important. > > Struct xvnode changed layout, no compat shims are provided. > > For struct xtty, dev_t tty device member was reduced to uint32_t. It > was decided that keeping ABI compat in this case is more useful than > reporting 64bit dev_t, for the sake of pstat. > > 4. Testing procedure. > > The ino64 project can be tested by cloning the project branch from > GitHub or by applying the patch at URL | attached> to a working tree. The authorative source is the > GitHub, I do not promise to update the review for each update. > > To clone from GitHub: > % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino64 > > To fetch the patch from Phabricator: > - Visit https://reviews.freebsd.org/D10439 > - Click "Download Raw Diff" at the upper right of the page > > Or > % arc patch D10439 > > After that, in the checkout directory do > % (cd sys/kern && touch syscalls.master && make sysent) > % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent) > If you use custom kernel configuration, ensure that > options COMPAT_FREEBSD11 > is included into the config. Then build world and kernel in the > usual way, install kernel, reboot, install new world. Do not make > shortcuts in the update procedure. Hey Kostik, On my HardenedBSD system, world compiled fine with the patch, but the kernel didn't compile. I've uploaded the log to: https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log This was from importing the patch from Phabricator into hardened/current/master in HardenedBSD. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
net/rubygem-signet causing poudriere to be unhappy
Hey All, It looks like the new net/rubygem-signet port is causing issues with poudriere: Error: Duplicated origin for rubygem-signet-0.7.3: security/rubygem-signet AND net/rubygem-signet. Rerun with -vv to see which ports are depending on these. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
www/chromium build failure on 12-CURRENT
Hey All, It looks like www/chromium fails to build on 12-CURRENT. Has anyone else run into this? The relevant erroring lines: BEGIN LOG clang++39 -MMD -MF obj/services/ui/ws/lib/window_manager_display_root.o.d -D_LIBCPP_TRIVIAL_PAIR_COPY_CTOR=1 -DV8_DEPRECATION_WARNINGS -DENABLE_MDNS=1 -DENABLE_NOTIFICATIONS -DENABLE_PEPPER_CDMS -DENABLE_PLUGINS=1 -DENABLE_PDF=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 -DUSE_CLIPBOARD_AURAX11=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DENABLE_WEBRTC=1 -DDISABLE_NACL -DENABLE_EXTENSIONS=1 -DENABLE_TASK_MANAGER=1 -DENABLE_THEMES=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DUSE_PROPRIETARY_CODECS -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DENABLE_MEDIA_ROUTER=1 -DFIELDTRIAL_TESTING_ENABLED -DCR_CLANG_REVISION=278861-1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL -DSK_IGNORE_DW_GRAY_FIX -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DSK_SUPPORT_GPU=1 -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_NOEXCEPT= -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -I../.. -Igen -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -Igen/shim_headers/harfbuzz_shim -I../../third_party/khronos -I../../gpu -I../../skia/config -I../../skia/ext -I../../third_party/skia/include/c -I../../third_party/skia/include/config -I../../third_party/skia/include/core -I../../third_party/skia/include/effects -I../../third_party/skia/include/images -I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops -I../../third_party/skia/include/pdf -I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports -I../../third_party/skia/include/utils -I../../third_party/skia/include/gpu -I../../third_party/skia/src/gpu -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -I../../third_party/mesa/src/include -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe -fcolor-diagnostics -fdebug-prefix-map=/wrkdirs/usr/ports/www/chromium/work/chromium-54.0.2840.100=. -pthread -m64 -march=x86-64 -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-undefined-var-template -Wno-nonportable-include-path -O2 -fno-ident -fdata-sections -ffunction-sections -g0 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -fno-threadsafe-statics -fvisibility-inlines-hidden -std=gnu++11 -fno-rtti -fno-exceptions -c ../../services/ui/ws/window_manager_display_root.cc -o obj/services/ui/ws/lib/window_manager_display_root.o In file included from ../../services/ui/ws/window_manager_display_root.cc:5: In file included from ../../services/ui/ws/window_manager_display_root.h:10: In file included from /usr/include/c++/v1/memory:599: /usr/include/c++/v1/__config:58:2: error: "_LIBCPP_TRIVIAL_PAIR_COPY_CTOR" is no longer supported.use _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR instead #error "_LIBCPP_TRIVIAL_PAIR_COPY_CTOR" is no longer supported. \ ^ 1 error generated. ninja: build stopped: subcommand failed. *** Error code 1 END LOG The full (21MB in size) build log is here: https://hardenedbsd.org/~shawn/logs/chromium-54.0.2840.100_1.log Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: Hash changes in the freebsd-ports GitHub mirror
On Fri, Dec 02, 2016 at 04:08:23PM +, Steven Hartland wrote:
> On 02/12/2016 15:12, Shawn Webb wrote:
> > On Fri, Dec 02, 2016 at 10:40:29AM +0100, Raphael Kubo da Costa wrote:
> >> Hi all,
> >>
> >> I tried running `git pull` a few minutes ago and had a ton of conflicts.
> >>
> >> It turns out all hashes after c96fb0418e545a569b5975b4d878a30a948c29d5
> >> ("fix issues related with USES=fonts" from 2015-07-18, aka r392404) are
> >> now different in all GitHub branches.
> >>
> >> Is anyone else experiencing this? Was this change intentional?
> > We at HardenedBSD are affected as well. Well, time to spend my weekend
> > resolving merge conflicts.
> >
> > Seems like any downstream project that relies on the GitHub mirror of
> > the ports tree will have issues. Major ouch.
> >
> Did someone do a force push?
Looks like the svn2git conversion script iis having issues:
https://lists.freebsd.org/pipermail/freebsd-git/2016-December/74.html
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
Re: Hash changes in the freebsd-ports GitHub mirror
On Fri, Dec 02, 2016 at 10:40:29AM +0100, Raphael Kubo da Costa wrote:
> Hi all,
>
> I tried running `git pull` a few minutes ago and had a ton of conflicts.
>
> It turns out all hashes after c96fb0418e545a569b5975b4d878a30a948c29d5
> ("fix issues related with USES=fonts" from 2015-07-18, aka r392404) are
> now different in all GitHub branches.
>
> Is anyone else experiencing this? Was this change intentional?
We at HardenedBSD are affected as well. Well, time to spend my weekend
resolving merge conflicts.
Seems like any downstream project that relies on the GitHub mirror of
the ports tree will have issues. Major ouch.
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
editors/flim broken
Hey there, It looks like editors/flim may be broken, causing Poudriere to fail the calculating dependencies stage. editors/flim now depends on a non-existent emacs port, editors/apel-emacs25. Here's the exact error from Poudriere: Error: editors/flim depends on nonexistent origin 'editors/apel-emacs25'; Please contact maintainer of the port to fix this. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: freebsd-update and portsnap users still at risk of compromise
On Wed, Aug 10, 2016 at 09:50:37AM +0100, Big Lebowski wrote: > On Tue, Aug 9, 2016 at 9:21 PM, Matthew Donovan <kit...@kitchetech.com> > wrote: > > > You mean operating system as distribution is a Linux term. There's not much > > different between HARDENEDBSD and FreeBSD besides that HardenedBSD fixes > > vulnerabilities and has a an excellent ASLR system compared to the proposed > > one for FreeBSD. > > > > And what are your sources on which you're formulating this statement? What > is the HBSD authors security, or even general coding, track record? How > well are they known for their code, whitepapers, implementations? I'd say, > not at all. You can have the example of their 'ASLR' code quality in the > FreeBSD reviews system, where known and respected coders point out very > basic and critical code mistakes, where well known and respected system > designers point out flaws in their lack of design, so on and so forth. The > only thing that's excellent about them is how they spread this opinion > about their code to other people, including you ;) > > I'd much rather take my bet with kib's implementation knowing who he is and > how long and how well he does what he does (that is, quality code for > FreeBSD) than untested, un-designed, self-procclaimed code from relatively > young, inexperienced and unknown person, that's not willing to take advices > on fixing their code, when given so. > > With all due respect :) Hey there, ASLR shouldn't be part of the discussion revolving the freebsd-update, portsnap, libarchive, and bspatch vulnerabilities. ASLR won't even help with these vulnerabilities in particular as they are logic vulnerabilities. ASLR helps make more difficult the successful exploitation of buffer overflows, format string vulnerabilities, etc. In HardenedBSD, we've fixed the two libarchive vulnerabilities that FreeBSD is vulnerable to. But the fixes are only band-aids until FreeBSD publishes their fixes, which they are planning on to do before 11.0-RELEASE goes out the door. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: security/openvpn build failure on 12-CURRENT/amd64
On Mon, Aug 01, 2016 at 02:26:39PM +, Matthias Andree wrote: > Hi Shawn, > > The compilation attempt was done on an invalid configuration and has zero > relevance whatsoever. As the log says: > > !!! Jail is newer than host. (Jail: 121, Host: 1100116) !!! > !!! This is not supported. !!! > !!! Host kernel must be same or newer than jail. !!! > !!! Expect build failures. !!! > > I wish the builders would stop even trying to build a package on a kernel > that is too old, it's just confusing and wasteful. > Hey Matthias, HardenedBSD's kernel and world matched and still had the very same build error. Here's the build log: http://pastebin.com/TEBih1Sx Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
security/openvpn build failure on 12-CURRENT/amd64
Hey All, It looks like security/openvpn fails to build on 12-CURRENT/amd64 on both FreeBSD's and HardenedBSD's build infrastructure. I've verified that it builds fine on latest 11-STABLE/amd64. Would this be a regression in 12-CURRENT? Log file from FreeBSD's build: http://beefy4.nyi.freebsd.org/data/head-amd64-default/p419204_s303419/logs/errors/openvpn-2.3.11.log Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: Firefox 47.0 hangs when accessing cnn.com
On Fri, Jun 10, 2016 at 04:29:52PM -0500, Bob Willcox wrote: > On Fri, Jun 10, 2016 at 01:01:42PM -0700, Kevin Oberman wrote: > > On Fri, Jun 10, 2016 at 12:36 PM, Bob Willcox <b...@immure.com> wrote: > > > > > On Fri, Jun 10, 2016 at 03:42:00PM +, Grzegorz Junka wrote: > > > > ... > > > > That sounds bad indeed. Have you tried to reinstall using the official > > > > pkg repository (not compiled on your machine)? > > > > > > > > BTW Firefox 47 just started crashing today for me. Nothing to do with > > > > scripts, some exception in one of the *.c files (according to the > > > > popup). I am now creating a new batch of packages with poudriere and > > > > will try to upgrade to a newer version. > > > > > > Ugh. Mine hasn't crashed, just hung to the point where I have to kill it. > > > Jan has suggested some things for me to try that I plan to do when I get > > > some time. I'll post how that went once I've tried them. > > > > > > Bob > > > > > > -- > > > Bob Willcox| Which is worse: ignorance or apathy? > > > b...@immure.com | Who knows? Who cares? > > > Austin, TX | > > > > > > > npviewer.bin is not part of firefox. It is a part of nspluginwrapper. If > > you uninstall it and restart firefox, does the problem go away? (Of course, > > you won't be able to view flash.) Have you followed Jan's suggestion to > > re-setup nspluginwrapper? NOTE: It must be installed by you with the UID > > you use to run firefox! Doing it as rot won't work. > > I haven't been able to follow Jan's suggestions yet (I'm at work currently). > I had done the setup for nspluginwrapper some time ago, but not since the > system update on 6/4 that sent me down this rat hole. I'll give that a try > first. > > Thanks, > Bob I'm running Firefox 47 on HardenedBSD and it's running like a champ. It includes W^X compatibility, PIE, and RELRO + BIND_NOW. I was able to successfully load CNN's site. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Using GitLab With Port Makefile
Hey freebsd-ports peeps, I'm writing a custom ports entry for my employer. We have an internal GitLab instance. I was wondering if it'd be possible to use USE_GITHUB with our internal GitLab, but instead of having the Ports system use GitHub to download the archive, use our GitLab instance. Is that possible? I see in ports/Mk/bsd.sites.mk that MASTER_SITE_GITHUB is appended to. But it looks like I can't override that. Let me know how best to proceed. Admittedly, I'm a newb at creating ports entries. Thanks, -- Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
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: [CFT] Call for testing pkg 1.5.0
On Tue, 2015-03-31 at 21:03 +0200, Baptiste Daroussin wrote: Hi all, We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), Hey Baptiste, Great work to you and all those involved in this project! I'm grateful to have such an awesome tool. For those of us who run our own package repos via Poudriere, what kinds of changes should we expect to make once pkg 1.5.0 is released? Do we need to do a full rebuild of our package repo? I'm also assuming that the upgrade path from 1.4.x to 1.5.0 will simply be as easy as running `pkg upgrade`, right? Thanks again for your hard work. Thanks, Shawn signature.asc Description: This is a digitally signed message part
Re: clamav-0.98.3_2: LibClamAV Warning: Cannot dlopen libclamunrar_iface...
On Sat, May 17, 2014 at 9:28 AM, Herbert J. Skuhra hsku...@eumx.net wrote: On Fri, 16 May 2014 07:22:41 +0200 Dr. Peter Voigt wrote: Am Thu, 15 May 2014 18:33:36 -0400 schrieb Renato Botelho ga...@freebsd.org: On Thursday, May 15, 2014 04:23:28 PM Shawn Webb wrote: On Thu, May 15, 2014 at 3:59 PM, Dr. Peter Voigt pvo...@uos.de wrote: After the upgrade to clamav-0.98.3_2 I am obtaining following error on every start of ClamAV: # service clamav-clamd start Starting clamav_clamd. LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - unrar support unavailable ClamAV, however, seems to work correctly. Is this a known issue? I am on 10.0-RELEASE-p3 amd64. Regards, Peter Hey Peter, This can be fixed by applying this patch: https://github.com/vrtadmin/clamav-devel/commit/d17ee49f75e23b43fadf745c27dc 4dd16ee372e5 CC'd on this email is the ports maintainer for ClamAV. Fixed. Thanks! Yeah, thanks, I've just pulled in clamav-0.98.3_3 which has this issue fixed. % pkg version -v |grep clamav clamav-0.98.3_3= up-to-date with port % sudo /usr/local/etc/rc.d/clamav-clamd start Starting clamav_clamd. LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - unrar support unavailable What revision should fix this issue? Did you forget to bump port revision? I'll rebuild clamav. Thanks. Hey Herbert, Applying this patch will fix the issue: https://github.com/vrtadmin/clamav-devel/commit/d17ee49f75e23b43fadf745c27dc4dd16ee372e5 Renato, can you please add that patch to the port? Thanks, Shawn ___ 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: clamav-0.98.3_2: LibClamAV Warning: Cannot dlopen libclamunrar_iface...
On Thu, May 15, 2014 at 3:59 PM, Dr. Peter Voigt pvo...@uos.de wrote: After the upgrade to clamav-0.98.3_2 I am obtaining following error on every start of ClamAV: # service clamav-clamd start Starting clamav_clamd. LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - unrar support unavailable ClamAV, however, seems to work correctly. Is this a known issue? I am on 10.0-RELEASE-p3 amd64. Regards, Peter Hey Peter, This can be fixed by applying this patch: https://github.com/vrtadmin/clamav-devel/commit/d17ee49f75e23b43fadf745c27dc4dd16ee372e5 CC'd on this email is the ports maintainer for ClamAV. Thanks, Shawn ___ 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: clamav-0.98.3_2: LibClamAV Warning: Cannot dlopen libclamunrar_iface...
On Thu, May 15, 2014 at 5:20 PM, Dr. Peter Voigt pvo...@uos.de wrote: Am Thu, 15 May 2014 16:23:28 -0400 schrieb Shawn Webb latt...@gmail.com: On Thu, May 15, 2014 at 3:59 PM, Dr. Peter Voigt pvo...@uos.de wrote: After the upgrade to clamav-0.98.3_2 I am obtaining following error on every start of ClamAV: # service clamav-clamd start Starting clamav_clamd. LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - unrar support unavailable ClamAV, however, seems to work correctly. Is this a known issue? I am on 10.0-RELEASE-p3 amd64. Regards, Peter Hey Peter, This can be fixed by applying this patch: https://github.com/vrtadmin/clamav-devel/commit/d17ee49f75e23b43fadf745c27dc4dd16ee372e5 CC'd on this email is the ports maintainer for ClamAV. Thanks, Shawn Shawn, thanks for your extremely quick reply. I am afraid, I am not yet experienced enough to apply a patch to files of a port that are not permanently present in the ports tree like configure and m4/reorganization/version.m4. Nevertheless, the issue is obviously ClamAV related and should be merged to a new version of security/clamav. Should I open a corresponding PR or does the CC-ed maintainer feel informed sufficiently? Regards, Peter Opening a PR never hurts. I'm sure Renato will see both. As you can see by the link I provided, the fix for this is in upstream ClamAV 0.98.4, which will be released in the near future (sorry, no exact ETA). Thanks, Shawn ___ 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: lang/php5: Update doesn't install libphp5.so anymore, www/apache24 fails to start
On Apr 04, 2014 07:28 PM +0200, O. Hartmann wrote: After updating ports today and a lot of the php-stuff, I get this error restarting apache24: httpd: Syntax error on line 162 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/libphp5.so into server: Cannot open /usr/local/libexec/apache24/libphp5.so I tried to rebuild apache24 as well as lang/php5 with first rmconfig and then config again avoiding missing something. No effect. What happened here? /usr/ports/UPDATING doesn't have any kind of information regarding this subject. Oliver I had this same issue, too. Installing www/mod_php5 will fix it. pgpgpwpe9s8eS.pgp Description: PGP signature
devel/libkolab failing to build on 11-current
devel/libkolab has been failing for the past few weeks. Log file from an 11-current/amd64 Poudriere build here: http://pastebin.com/kfjkMpE7 ___ 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: FreeBSD Port: emulators/virtualbox-ose
On Wed, Dec 11, 2013 at 3:42 PM, Mike Jakubik mike.jaku...@intertainservices.com wrote: On 12/11/13 15:32, Bernhard Fröhlich wrote: I can only repeat myself. It will not happen any day soon because clang does not support global register variables and they do not seem to have any interest to implement that. Got it. Could you please send me the following output just to verify: strings /usr/lib/libstdc++.so.6 | grep GLIBCXX $ strings /usr/lib/libstdc++.so.6 | grep GLIBCX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_FORCE_NEW make delete-old and delete-old-libs does not remove anything from my system at this point, i am going to try compile again but with gcc47 this time. Thanks! I'm not sure if this fixed it, because I made this change in the middle of some recent changes with the port. I added WITH_GCC=yes and WITH_GNUCXX=yes to my /etc/src.conf Hope that helps, Shawn ___ 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: problem with clamav
On Fri, Nov 22, 2013 at 8:57 PM, AN a...@neu.net wrote: FreeBSD .rootbsd.net 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r258260M: Sun Nov 17 13:01:19 EST 2013 rootbsd.net:/usr/obj/usr/src/sys/GENERIC amd64 # portupgrade -va --- Session started at: Fri, 22 Nov 2013 20:46:56 -0500 [Reading data from pkg(8) ... - 81 packages found - done] ** Port marked as IGNORE: security/clamav: Unknown version of GCC specified (USE_GCC=any) --- Listing the results (+:done / -:ignored / *:skipped / !:failed) - security/clamav (marked as IGNORE) --- Packages processed: 0 done, 1 ignored, 0 skipped and 0 failed --- Session ended at: Fri, 22 Nov 2013 20:47:00 -0500 (consumed 00:00:03) # pkg info |grep gcc gcc-4.6.4 GNU Compiler Collection 4.6 gcc-ecj-4.5Eclipse Java Compiler used to build GCC Java # pkg info |grep clam clamav-0.98_2 Command line virus scanner written entirely in C Is clamav broken on current? Any suggestions on how to proceed? Thanks in advance. The problem wouldn't be with ClamAV, but with the port entry. ClamAV currently doesn't build with clang on 11-CURRENT, but it does indeed work with gcc (I'm building manually from source checked out via git, and am using gcc/g++ 4.6.4 from ports). Maybe the port maintainer has some input. Thanks, Shawn ___ 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: Chromium and HEAD
Same for me. Built using Poudriere. On Thu, Oct 3, 2013 at 10:30 AM, Lars Engels lars.eng...@0x20.net wrote: On Wed, Oct 02, 2013 at 10:10:24PM -0400, Sam Fourman Jr. wrote: using a recent FreeBSD amd64 FreeBSD NewBSD 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #0 r255942: Sun Sep 29 20:05:41 UTC 2013 I am running chromium built with default options(clang33 from ports) when you use the address bar to search, chromium will coredump if the first letter you type is the letter a is anyone else seeing this? Same for me using the version from pkg-test. ___ 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
`make index` broken
I'm on 11-current/amd64. I'm not sure if it's specific to me, but it looks
like a change to the net/openbgpd port is causing `make index` to fail with
the following error message:
make[5]: Unknown modifier ')'
make[5]: Unclosed variable specification (expecting '}') for PORT_OPTIONS
(value ) modifier )
make[5]: /usr/ports/net/openbgpd/Makefile line 31: Malformed conditional
(${PORT_OPTIONS:MIPV6LLPEER))
make[5]: Fatal errors encountered -- cannot continue=== net/openbgpd failed
*** [describe.net] Error code 1
Thanks,
Shawn
___
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
sysutils/cdrtools build broken with poudriere
Hey all, I can't build sysutils/cdrtools in a 9-stable/amd64 jail using an up-to-date ports-mgmt/poudriere. Build log is below. Thanks, Shawn Building sysutils/cdrtools build started at Sat Jun 15 04:42:01 EDT 2013 port directory: /usr/ports/sysutils/cdrtools building for: FreeBSD 90amd64-local-job-03 9.1-STABLE FreeBSD 9.1-STABLE amd64 maintained by: mar...@freebsd.org ident warning: no id keywords in /tank/poudriere/jails/data/build/90amd64-local/ref/../03//usr/ports/sysutils/cdrtools/Makefile Makefile ident: Poudriere version: 3.0.3 ---Begin Environment--- OSVERSION=901504 UNAME_v=FreeBSD 9.1-STABLE UNAME_r=9.1-STABLE BLOCKSIZE=K MAIL=/var/mail/root STATUS=1 MASTERMNT=/tank/poudriere/jails/data/build/90amd64-local/ref PKG_EXT=txz FORCE_PACKAGE=yes tpid=25157 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin POUDRIERE_BUILD_TYPE=bulk NBPARALLEL=8 PKGNG=1 PKGNAME=cdrtools-3.00_2 PKG_DELETE=/usr/local/sbin/pkg delete -y -f PKG_ADD=/usr/local/sbin/pkg add PWD=/usr/local/etc/poudriere.d/ports MASTERNAME=90amd64-local USER=root HOME=/root POUDRIERE_VERSION=3.0.3 SKIPSANITY=1 LOCALBASE=/usr/local PACKAGE_BUILDING=yes ---End Environment--- ---Begin OPTIONS List--- ---End OPTIONS List--- --CONFIGURE_ARGS-- --End CONFIGURE_ARGS-- --CONFIGURE_ENV-- TMPDIR=/tmp TMPDIR=/tmp SHELL=/bin/sh CONFIG_SHELL=/bin/sh MAKE=gmake --End CONFIGURE_ENV-- --MAKE_ENV-- PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin CCOM=cc GMAKE_NOWARN=true INS_BASE=/usr/local INS_RBASE=/usr/local TMPDIR=/tmp OSDEFS=-I/usr/local/include TMPDIR=/tmp SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local MOTIFLIB=-L/usr/local/lib -lXm -lXp LIBDIR=/usr/lib CC=cc CFLAGS=-O2 -pipe -fno-strict-aliasing CPP=cpp CPPFLAGS= LDFLAGS= CXX=c++ CXXFLAGS=-O2 -pipe -fno-strict-aliasing MANPREFIX=/usr/local BSD_INSTALL_PROGRAM=install -s -o root -g wheel -m 555 BSD_INSTALL_LIB=install -s -o root -g wheel -m 444 BSD_INSTALL_SCRIPT=install -o root -g wheel -m 555 BSD_INSTALL_DATA=install -o root -g wheel -m 444 BSD_INSTALL_MAN=install -o root -g wheel -m 444 --End MAKE_ENV-- --SUB_LIST-- PREFIX=/usr/local LOCALBASE=/usr/local DATADIR=/usr/local/share/cdrtools DOCSDIR=/usr/local/share/doc/cdrtools EXAMPLESDIR=/usr/local/share/examples/cdrtools WWWDIR=/usr/local/www/cdrtools ETCDIR=/usr/local/etc/cdrtools --End SUB_LIST-- ---Begin make.conf--- USE_PACKAGE_DEPENDS=yes BATCH=yes WRKDIRPREFIX=/wrkdirs PACKAGES=/packages DISTDIR=/distfiles /usr/local/etc/poudriere.d/90amd64-make.conf WITH_PKGNG=yes DISABLE_MAKE_JOBS=yes ---End make.conf--- === Cleaning for cdrtools-3.00_2 ===phase: check-config = ===phase: pkg-depends === cdrtools-3.00_2 depends on file: /usr/local/sbin/pkg - not found ===Verifying install for /usr/local/sbin/pkg in /usr/ports/ports-mgmt/pkg === Installing existing package /packages/All/pkg-1.0.13.txz Installing pkg-1.0.13... done If you are upgrading from the old package format, first run: # pkg2ng === Returning to build of cdrtools-3.00_2 = ===phase: fetch-depends = ===phase: fetch You may use the following build option(s): WITH_CDDA2MP3=yes builds with cdda2mp3 (requires audio/lame) WITH_CDDA2OGG=yes builds with cdda2ogg (requires audio/vorbis-tools) WITH_RSCSI=yes builds with the rscsi daemon which provides access to local SCSI-devices over the network (the client-side in cdda2wav, cdrecord, etc. is built unconditionally). BEWARE: The rscsi binary will be installed suid root as this is the preferred way of setting it up. === Fetching all distfiles required by cdrtools-3.00_2 for building = ===phase: checksum You may use the following build option(s): WITH_CDDA2MP3=yes builds with cdda2mp3 (requires audio/lame) WITH_CDDA2OGG=yes builds with cdda2ogg (requires audio/vorbis-tools) WITH_RSCSI=yes builds with the rscsi daemon which provides access to local SCSI-devices over the network (the client-side in cdda2wav, cdrecord, etc. is built unconditionally). BEWARE: The rscsi binary will be installed suid root as this is the preferred way of setting it up. === Fetching all distfiles required by cdrtools-3.00_2 for building =
KDE4 Widgets Missing
Hey All, I'm sorry to bug you all about something so trivial, but I can't find anything Googling about this. I don't want to file a bug report (unless actually necessary). A few months ago, I deinstalled KDE4 (prior to the ports tree updating to the 4.9.5 release) to switch to something a little lighter. I've now reinstalled KDE4 via the same x11/kde4 port I used before. KDE 4.9.5 is installed and everything's working great. However, when I edit the panel at the bottom of the screen and select Add Widgets, no widgets appear. I've installed a few other widgets and those don't show either. Because of its size, I can't figure out where to look to see why kde4's misbehaving. I've grepped through /usr/local/kde4/share to see if there's some old config left from the old install of kde4 that doesn't apply anymore (or should be replaced with a more current config). No luck there. I'm on 10-current (an older release, dated 01 Mar 2013, r247527). My uname output is: FreeBSD pwnie.clamav.dev 10.0-CURRENT FreeBSD 10.0-CURRENT #18 r247527+2f5def5: Fri Mar 1 01:09:10 EST 2013 shawn@pwnie:/usr/obj/usr/src/sys/SEC amd64 My ports tree is completely up-to-date and all installed ports are up-to-date as well. This isn't anything high-priority, more of a want than a need right now. Let me know if you have any questions, comments, or suggestions. Thanks, Shawn ___ 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: KDE4 Widgets Missing
Nevermind. I found the reason why: it's because I compiled with clang rather than gcc. Reference: http://forums.freebsd.org/showthread.php?p=210232 On Wed, Mar 20, 2013 at 4:32 PM, Shawn Webb latt...@gmail.com wrote: Hey All, I'm sorry to bug you all about something so trivial, but I can't find anything Googling about this. I don't want to file a bug report (unless actually necessary). A few months ago, I deinstalled KDE4 (prior to the ports tree updating to the 4.9.5 release) to switch to something a little lighter. I've now reinstalled KDE4 via the same x11/kde4 port I used before. KDE 4.9.5 is installed and everything's working great. However, when I edit the panel at the bottom of the screen and select Add Widgets, no widgets appear. I've installed a few other widgets and those don't show either. Because of its size, I can't figure out where to look to see why kde4's misbehaving. I've grepped through /usr/local/kde4/share to see if there's some old config left from the old install of kde4 that doesn't apply anymore (or should be replaced with a more current config). No luck there. I'm on 10-current (an older release, dated 01 Mar 2013, r247527). My uname output is: FreeBSD pwnie.clamav.dev 10.0-CURRENT FreeBSD 10.0-CURRENT #18 r247527+2f5def5: Fri Mar 1 01:09:10 EST 2013 shawn@pwnie:/usr/obj/usr/src/sys/SEC amd64 My ports tree is completely up-to-date and all installed ports are up-to-date as well. This isn't anything high-priority, more of a want than a need right now. Let me know if you have any questions, comments, or suggestions. Thanks, Shawn ___ 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
net-im/telepathy-haze update fails
I've been having issues updating net-im/telepathy-haze on amd64 10-CURRENT r247527. Pasted below is the log from `portmaster --no-confirm -wGD net-im/telepathy-haze`: ]0;portmaster: telepathy-haze-0.4.0_5 === Currently installed version: telepathy-haze-0.4.0_5 === Port directory: /usr/ports/net-im/telepathy-haze === Launching 'make checksum' for net-im/telepathy-haze in background === Gathering dependency list for net-im/telepathy-haze from ports === Initial dependency check complete for net-im/telepathy-haze ]0;portmaster: telepathy-haze-0.4.0_5 === Starting build for net-im/telepathy-haze === === All dependencies are up to date === Cleaning for telepathy-haze-0.6.0 === telepathy-haze-0.6.0 depends on file: /usr/local/sbin/pkg - found === Extracting for telepathy-haze-0.6.0 = SHA256 Checksum OK for telepathy-haze-0.6.0.tar.gz. === Patching for telepathy-haze-0.6.0 === telepathy-haze-0.6.0 depends on executable: xsltproc - found === telepathy-haze-0.6.0 depends on executable: gmake - found === telepathy-haze-0.6.0 depends on shared library: purple - found === telepathy-haze-0.6.0 depends on shared library: idn - found === telepathy-haze-0.6.0 depends on shared library: telepathy-glib - found === Configuring for telepathy-haze-0.6.0 === FreeBSD 10 autotools fix applied to /usr/ports/net-im/telepathy-haze/work/telepathy-haze-0.6.0/configure === FreeBSD 10 autotools fix applied to /usr/ports/net-im/telepathy-haze/work/telepathy-haze-0.6.0/m4/libtool.m4 === FreeBSD 10 autotools fix applied to /usr/ports/net-im/telepathy-haze/work/telepathy-haze-0.6.0/aclocal.m4 cd: /usr/ports/net-im/telepathy-haze/work/telepathy-telepathy-haze-0.6.0: No such file or directory env: ./configure: No such file or directory === Script configure failed unexpectedly. Please report the problem to gn...@freebsd.org [maintainer] and attach the /usr/ports/net-im/telepathy-haze/work/telepathy-telepathy-haze-0.6.0/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg info -g -Ea). *** [do-configure] Error code 1 Stop in /usr/ports/net-im/telepathy-haze. === make failed for net-im/telepathy-haze === Aborting update Terminated === You can restart from the point of failure with this command line: portmaster flags net-im/telepathy-haze Thanks, Shawn ___ 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: net-im/telepathy-haze update fails
On Tue, Mar 12, 2013 at 1:11 PM, Scot Hetzel swhet...@gmail.com wrote:
On Tue, Mar 12, 2013 at 11:28 AM, Shawn Webb latt...@gmail.com wrote:
I've been having issues updating net-im/telepathy-haze on amd64
10-CURRENT r247527. Pasted below is the log from `portmaster --no-confirm
-wGD net-im/telepathy-haze`:
]0;portmaster: telepathy-haze-0.4.0_5
=== Currently installed version: telepathy-haze-0.4.0_5
=== Port directory: /usr/ports/net-im/telepathy-haze
=== Launching 'make checksum' for net-im/telepathy-haze in background
=== Gathering dependency list for net-im/telepathy-haze from ports
=== Initial dependency check complete for net-im/telepathy-haze
]0;portmaster: telepathy-haze-0.4.0_5
=== Starting build for net-im/telepathy-haze ===
=== All dependencies are up to date
=== Cleaning for telepathy-haze-0.6.0
=== telepathy-haze-0.6.0 depends on file: /usr/local/sbin/pkg - found
=== Extracting for telepathy-haze-0.6.0
= SHA256 Checksum OK for telepathy-haze-0.6.0.tar.gz.
=== Patching for telepathy-haze-0.6.0
=== telepathy-haze-0.6.0 depends on executable: xsltproc - found
=== telepathy-haze-0.6.0 depends on executable: gmake - found
=== telepathy-haze-0.6.0 depends on shared library: purple - found
=== telepathy-haze-0.6.0 depends on shared library: idn - found
=== telepathy-haze-0.6.0 depends on shared library: telepathy-glib -
found
=== Configuring for telepathy-haze-0.6.0
=== FreeBSD 10 autotools fix applied to
/usr/ports/net-im/telepathy-haze/work/telepathy-haze-0.6.0/configure
=== FreeBSD 10 autotools fix applied to
/usr/ports/net-im/telepathy-haze/work/telepathy-haze-0.6.0/m4/libtool.m4
=== FreeBSD 10 autotools fix applied to
/usr/ports/net-im/telepathy-haze/work/telepathy-haze-0.6.0/aclocal.m4
cd: /usr/ports/net-im/telepathy-haze/work/telepathy-telepathy-haze-0.6.0:
No such file or directory
env: ./configure: No such file or directory
The problem seems to be the extra 'telepathy-', try commenting out
WRKSRC= ${WRKDIR}/telepathy-${PORTNAME}-${DISTVERSION}
in the ports Makefile.
That worked. 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
Re: sysutils/pacman: use in FreeBSD?
On Fri, Jan 25, 2013 at 2:28 AM, Thomas Mueller mueller6...@bellsouth.netwrote: I see to my surprise, in http://www.freshports.org/commits.php , that pacman from Archlinux has just been ported to FreeBSD. But how would pacman be used in FreeBSD, considering we already have ports and pkgng? Would pacman in FreeBSD be only for binary packages, or would it be used with Arch Build System to build packages from source as is done with FreeBSD ports and NetBSD pkgsrc? Take a look at http://archbsd.net/. ___ 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
VirtualBox 4.2.6 and VBoxHeadless VNC
Hey All, I just upgraded VirtualBox to 4.2.6 on my headless dev server. I use VNC with VBoxHeadless. After upgrading, I had to change the command-line options I use for starting the VMs (which is totally fine). It seems that now VNC is asking for a password, which I never set. Prior to upgrading, VNC was passwordless. Attempting to connect with a blank password fails to work as does password. I'm not sure where to proceed from here. Anyone know how to disable the password or what the default password is? Thanks, Shawn Webb ___ 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: VirtualBox 4.2.6 and VBoxHeadless VNC
On Wed, Jan 9, 2013 at 2:52 PM, Larry Rosenman l...@lerctr.org wrote: -e VRDEproperty VNCPassword=whatever That works. Thanks! Another question. After pausing the VM by calling `VBoxManage controlvm [VM name here] savestate` I now can't resume execution by calling `VBoxHeadless -s [VM name here] [more arguments here for VNC]`. What would be the proper way to resume execution of a VM after its been paused via savestate? The error I'm getting is this: VBoxManage: error: Cannot resume the machine as it is not paused (machine state: Saved) VBoxManage: error: Details: code VBOX_E_INVALID_VM_STATE (0x80bb0002), component Console, interface IConsole, callee nsISupports VBoxManage: error: Context: Resume() at line 120 of file VBoxManageControlVM.cpp Thanks, Shawn ___ 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: (semi-)official git mirror of ports svn repo?
I'm trying to get one up on github at https://github.com/lattera/freebsd-ports. But I haven't been successful as of yet. Doing `git push -u github master` always times out on github's side. If anyone else has been successful, please let me know. Thanks, Shawn On Mon, Jul 23, 2012 at 5:05 PM, Andriy Gapon a...@freebsd.org wrote: Do we have a (semi-)official git mirror of the new ports _svn_ repo? Something either FreeBSD hosted/managed or maintained by prominent ports developers on github/gitorious/elsewhere? I looked at gitorious, github and freebsd.your.org and only this github repository seems to be active: https://github.com/freebsd/freebsd-ports/commits/master But note sure if it based off svn. -- Andriy Gapon ___ 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Need a little help with a dynamic linking problem
Without being able to look at the details in-depth myself, it looks like the shared object is looking for a symbol which the RTLD can't resolve. The symbol is defined in the gthumb application itself. Is that symbol exported such that shared objects can reference it? If the problem is still unresolved by tomorrow, I can draft up a sample and confirm my suspicions (that non-exported symbols won't be resolvable by dynamically-loaded shared objects). Thanks, Shawn Sent from my Android 4.0 device. Please forgive any spelling or grammatical errors. On Apr 25, 2012 6:02 PM, Ronald F. Guilmette r...@tristatelogic.com wrote: My question relates to a port that I am doing of gthumb v2.14.3 to FreeBSD. Because gthumb is fundamentally a gnome application, I am cross-posting my question to both the ports and gnome mailing lists. (My apologies if that means that some of you see this twice.) After a modest but unexpected amount of gnashing of teeth and tearing of hair, I have been able to get gthumb 2.14.3 built and installed on my FreeBSD 8.2 system. Now comes to the fun part... I have installed the whole thing under a special (temporary) directory that I created called /usr/local/hacked. When I try to run the gthumb binary that I built and install, I am getting the following perplexing error message: /libexec/ld-elf.so.1: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: Undefined symbol gth_viewer_page_get_type Quite obviously, I have been away from working on the GNU software development toolchain (and its friends, like ld-elf.so) for far far too long, because I no longer even know how this stuff is even supposed to work, i.e. when it is (knock on wood) working correctly. So if someone who knows this stuff can take pity on me and pass me a clue about what I need to do to resolve the above dynamic linking failure, I sure would appreciate it. Some relevant background: The main gthumb binary is installed in /usr/local/hacked/bin/gthumb and that's what I am running when I run it. It seems pretty obviously to me that the main gthumb executable, when executed, is then trying to dynamically pull in various of the *.so shared library files that got installed into /usr/local/hacked/lib/gthumb/extensions directory as part of the nominal build+install process for gthumb. One last important point: I've checked, and the symbol gth_viewer_page_get_type _is_ in fact defined. It is defined within the main gthumb executable itself: % nm gthumb | fgrep gth_viewer_page_get_type 004aaf10 T gth_viewer_page_get_type So, um, sombody please pass me a clue... How come the dynamic linker doesn't seem to know that the symbol it is looking for was and is defined in the main executable file that the present process originated with? (This specific lack of cognition on the part of the dynamic linker seems to me to be rather reminicent of Alzheimer's.) Regards, rfg P.S. I have already tried both of the following commands prior to executing my gthumb executable and neither of these made a bit of difference to the outcome. I still got the exact same dynamic linker (fatal) error in both cases... setenv LD_LIBRARY_PATH /usr/local/hacked/bin setenv LD_LIBRARY_PATH /usr/local/hacked/lib/gthumb/extensions ___ 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
`make index` broken on 9-stable
Hey freebsd-ports, Trying to run a `make index` in the root of my ports tree. What can or should I do to fix it? My ports tree is up-to-date as of 09 Feb 2012 8:40 AM MST (GMT-7). Output below: === BEGIN OUTPUT === [shawn@fbsd-sec /usr/ports]$ uname -a FreeBSD fbsd-sec 9.0-STABLE FreeBSD 9.0-STABLE #2: Fri Feb 3 11:44:52 MST 2012 shawn@fbsd-sec:/usr/obj/src/sys/SEC amd64 [shawn@fbsd-sec /usr/ports]$ make index Generating INDEX-9 - please wait..Makefile, line 1: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 1 error Before reporting this error, verify that you are running a supported version of FreeBSD (see http://www.FreeBSD.org/ports/) and that you have a complete and up-to-date ports collection. (INDEX builds are not supported with partial or out-of-date ports collections -- in particular, if you are using cvsup, you must cvsup the ports-all collection, and have no refuse files.) If that is the case, then report the failure to po...@freebsd.org together with relevant details of your ports configuration (including FreeBSD version, your architecture, your environment, and your /etc/make.conf settings, especially compiler flags and WITH/WITHOUT settings). Note: the latest pre-generated version of INDEX may be fetched automatically with make fetchindex. *** Error code 1 Stop in /usr/ports. *** Error code 1 Stop in /usr/ports. [shawn@fbsd-sec /usr/ports]$ cat /etc/make.conf # added by use.perl 2012-01-26 11:11:51 PERL_VERSION=5.12.4 === END OUTPUT === Thanks, Shawn ___ 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
