[NEW PORT] net-p2p/lidarr: Music collection manager for Usenet and BitTorrent users
Hi all, My apologies if this is not the correct place to post this. Would a committer be available to review this New Port request? portlint and testport are OK. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234233 Regards, Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: DoveCot 2.3
On Mar 07 09:17, The Doctor wrote: What are the hold ups for Dovecot 2.3 ? You, constantly asking this list why they haven't upgraded any ports to the latest versions but not actually providing any patches yourself to help the volunteers do this more quickly. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Call for help: www/nginx and 3rd party module
On Feb 21 17:18, Jochen Neumeister wrote: Which 3rd party modules do you use, which the port itself provides? This type of thing may be better suited for an online webpage type survey rather than potentially getting lots of posts to the mailing list with similar things? I always use and would greatly miss HTTP_DAV_EXT. Because for some inexplicable reason they won't put this functionality in the core DAV. I've also used HTTP_GEOIP2 in the past for a couple of things, but I wouldn't miss this one quite as much now. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: All those notes...
On Jan 08 14:44, Dave Horsfall wrote: Why would /usr/local/etc/apache24/httpd.conf need to be removed if not needed? Surely as I've just upgraded it, I might want it? The notes are for people installing the port/package for the very first time or for people removing the package. It's telling you things that you should do to get it working initially or how to clean up old files that are no longer used now you've deleted it. You are only seeing these notes because the act of upgrading them removes the old package and then installs the new package. If you have simply upgraded it then you can likely completely ignore all of these notes and instead you should take note of anything that is written in /usr/ports/UPDATING which relates to upgrades for your specific packages. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Status of portupgrade and portmaster?
On Oct 02 11:51, Don Lewis wrote:
Yes, but at least the poudriere jail doesn't build the kernel bits. The
real pain point is that when you update the jail, the next bulk package
build will toss all the previously built packages and force a full
rebuild from scratch. That makes sense if you believe that the contents
of the jail affect the contents of the packages build using that jail.
If you don't think that is true, then why bother to update the jail.
That is a good point and it does seem an overkill if you think not much
has changed in the jail to warrant it. It doesn't do it every time, only
when they increment the osrel number.
There is a way around it. I sometimes run this script which updates the
jail to be the same as my host.
#/bin/sh
V1=`uname -r`
V2=`sysctl -n kern.osreldate`
JV=`find /var/poudriere/data/packages/ -depth 2 -name .jailversion`
echo "${V1} ${V2}" > ${JV}
echo "${JV} set to ${V1} ${V2}"
--
Matt
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Status of portupgrade and portmaster?
On Oct 02 20:01, Marco Beishuizen wrote: On Mon, 2 Oct 2017, the wise Don Lewis wrote: Yes it can. If you use the svn method when creating a jail you can chose any arbitrary source branch from the svn repository and then you can specify any desired svn revision on that branch when you update the jail. You would probably want to use this method when building ports for 12.0-CURRENT rather than creating the jail using a 12.0-CURRENT snapshot. I'm running 11.1-STABLE now, upgrading every few months or when there is an important security fix. Do I have to build a new system twice in that case (once my running system and once the poudriere jail)? What I do is to initially create the jail using poudriere jail -c -j 11 -m src=/usr/src and then I upgrade the jail using poudriere jail -u -j 11. These commands use the existing /usr/src and /usr/obj trees from the host system buildworld/kernel. It doesn't need to be rebuilt. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Status of portupgrade and portmaster?
On Oct 02 12:05, Vlad K. wrote: On 2017-10-02 11:57, abi wrote: 2. Dependency chain is not updated - if I disable B feature on port A, poudriere asks me for options of ports implementing B. I have to Ctrl+C after any option change. I find that annoying as well, but isn't that just how the config-recursive ports framework target works? Poudriere is really using the ports make targets here. Do synth or portmaster do it differently? Synths philosophy was that you should have the absolute bare minimum of options set and John wrote a script to do just this in /usr/ports/Tools/scripts/redundant-opt-files.sh to delete any which just have defaults in them. My method with poudriere is to maintain two files, pkglist which is the list of ports that I want to bulk build, and optlist which is the list of ports for which I don't want the default options. This one is a hugely cut down list. I then occasionally run poudriere options -n -j jailname -f optlist so that it non-recursively only gives me a dialog for the ports with non-default options. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Status of portupgrade and portmaster?
On Oct 02 09:07, Carmel NY wrote: On Sun, 1 Oct 2017 23:49:14 +0100, Matthew Seaman stated: On 01/10/2017 11:34, Carmel NY wrote: 1. Does it determine out-of-date update packages automatically or does the user have to determine that what is out-of-date and feed them to poudriere manually and in the proper order? Automatic. 2. From what I have read, the user is required to install each package manually. Is that correct? Poudriere builds a repository. You then have to type 'pkg upgrade' or 'pkg install foo' to update your live system. Most people do not find this particularly taxing. From the "pkg-descr" file: poudriere is a tool primarily designed to test package production on FreeBSD. However, most people will find it useful to bulk build ports for FreeBSD. While it will undoubtedly work, it is still more complex than the average desktop user requirers. Synth fits the bill nicely by being, for the most part, easy to understand and run. I am already on my forth "ports maintenance" program having used portmanager, portmaster, portupgrade and now synth. At this point, I would almost rather switch to a new OS before abandoning synth for something that IMHO is just overkill for the average user. Just my 2¢. Of course if you did move to a different OS then the chances are you would be using a binary package repository and not compiling any software from source. So you wouldn't have any choice over the options that these packages were built with. If you are happy enough to do this then you may as well just abandon building ports on FreeBSD anyway and just use the pkg tool from the official FreeBSD repository. This is the easiest option surely. For what it's worth I've used both synth and poudriere and whilst poudriere is slightly heavier to use because of the requirement to create a build jail first, once that step has been done it's pretty much identical to using synth really. My workflow is simply this: poudriere ports -u (update the ports tree) poudriere bulk -j 11 -f pkglist (check for any updates and build any packages listed in the pkglist file) pkg upgrade (upgrade any upgraded packages) That's it. The same workflow on synth is: svn up /usr/ports synth build pkglist pkg upgrade Pretty similar if you ask me. OK you could use synth upgrade-system and do it in one command rather than two but then you're building everything on the host system and not a specific list. Also I like the extra pkg stage, it gives me a chance to see what pkg is about to do and abort it if it wants to do something insane. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Status of portupgrade and portmaster?
On Sep 29 20:23, Kurt Jaeger wrote: Hi! What is one officially supposed to use to build and upgrade packages from source? I doubt that we already have a 'official' consensus, but buildung using poudriere, while expensive from the hardware resource point of view, looks to me as the most stable way to do it. I agree. Portmaster was useful for many years but these days it is being left behind. The expectation is that ports are built in a clean room environment and portmaster does not provide that. I used synth for several months and it is a great tool. It works fine, but my problem with it is that the developer was forced out of FreeBSD and it needs an ada compiler. I think on FreeBSD 12 the ada compiler is broken isn’t it? Meaning synth will break. For this reason I switched to poudriere and that works fine for me. As that is the tool used by the pkg builders themselves I know it will work. For example we are shortly getting flavors support in the ports tree. I think the author of synth has already said he is not going to support this whereas poudriere will straight away. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: synth install ... builds but does not always install named packages
On Sep 15 08:23, Thomas Mueller wrote: In some cases, the named packages failed to install the first time (math/gnumeric and editors/abiword), and in other cases desired dependencies didn't install (devel/nasm and sysutils/coreutils, for instance). I need some of those build dependencies for other things like, for instance, cross-compiling Haiku and cross-compiling Linux toolchains, or other FreeBSD ports. Is there anything I can specify to install those build dependencies, and how do I go through /var/synth/live-packages/All and pkg info -a to install those packages that failed to install without missing something? Synth runs faster and more gracefully than portmaster, but portmaster installed everything that it built. Tom Maybe something along the lines of pkg install -g * ? I'm not sure, but -g lets you do a glob pattern. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: synth install ... builds but does not always install named packages
On Sep 15 07:34, Thomas Mueller wrote: I am building up a system (FreeBSD 11.1-STABLE amd64) using synth, but even when the packages build and appear in /var/synth/live_packages/All , some of the packages don't install. When I type "which gnumeric", "which bison", "which abiword", I just get a blank, and the executable files don't appear in /usr/local/bin . This happened with math/gnumeric, editors/abiword-docs, among others. I subsequently installed those packages by typing "synth install math/gnumeric" and "synth install editors/abiword-docs", but how do I find all the others that built and are listed in /var/synth/live_packages/All but did not install? I see "ls -l /var/synth/live_packages/All" has 657 lines, while "pkg info -a" produces 544 lines. I piped to "more", then hit G to go to the end, then Ctrl-G, which showed the number of lines. This may not tell the whole story, but makes me believe there is a disparity, and ask how to find and install those packages that built but didn't install. Has anybody else been stung by this bug? Tom Do you actually want those packages installed? The usual reason is that they are build dependencies only required for building another package and therefore they are in the repo but not installed. If they are run dependencies actually required for another package to run then they should be installed. Freshports is a good site for looking at this. http://www.freshports.org/ If you search for something it tells you what is build and what is run. Alternatively you can look at the ports Makefile for lines such as BUILD_DEPENDS, RUN_DEPENDS, LIB_DEPENDS etc. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Pkg does not upgrade if more than one repository is defined
On Jul 28 11:40, Miroslav Lachman wrote:
Matthias Fechner wrote on 2017/07/28 10:55:
Dear all,
I have a problem with pkg and I'm not sure if it is a bug in pkg or a
configuration issue.
I work on new version on ports which are in a separate poudriere
repository (to be able to easily test it).
I have now two configuration files in /usr/local/etc/pkg/repos,
poudriere.conf:
poudriere: {
url: "https://pkg.fechner.net/packages/110amd64-default";,
mirror_type: "pkg+http",
signature_type: "pubkey",
pubkey: "/usr/local/etc/ssl/certs/pkg.cert",
enabled: yes,
priority: 1
}
this is the standard repo which contains all stable packages.
Now I have a new version (in this case for gitlab) at gitlab.conf:
gitlab: {
url: "https://pkg.fechner.net/packages/110amd64-gitlab";,
mirror_type: "pkg+http",
signature_type: "pubkey",
pubkey: "/usr/local/etc/ssl/certs/pkg.cert",
enabled: yes,
priority: 10
}
The priority is higher and some package there have a higher version number.
But if I execute now 'pkg upgrade' pkg does not upgrade packages which
have a higher version from the gitlab repository, but stick to the
poudriere repository.
I also tried to do a 'pkg update -f; pkg upgrade' but it does not help.
Is there something wrong with my configuration or is this a bug in pkg?
If I understand you correctly, you have package A-1.0 installed from
repo "poudriere" and now you have package A-1.1 in repo "gitlab" and
you want to upgrade this package "A" to version 1.1.
Is it right?
I think that crossrepo upgrade is not automatic if package is in both
repositories but it work if package is missing from previous repo and
it it intentional.
I have more repositories too (different PHP version, different python
versions but common utilities etc.) so packages are not
unintentionally upgraded / downgraded.
But if you want to upgrade package A from different repo, you can
choose the repo:
-r reponame, --repository reponame
Install packages from only the named repository, irrespective
of the configured ``active'' status from repo.conf.
You can try
pkg install -r gitlab -f A
or
pkg upgrade -r gitlab -f A
where A is you package(s) name.
Miroslav Lachman
This might also be related to the CONSERVATIVE_UPGRADE setting of
pkg.conf. According to the man page:
CONSERVATIVE_UPGRADE: boolean
Ensure in multi repository mode that the priority is
given as much as possible to the repository where a
package was first installed from. Default: YES.
--
Matt
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: What to do when the port fails in poudriere with "Too many open files" ?
On Jun 28 22:38, Yuri wrote: I have the port that builds fine without poudriere, but in poudriere it always fails with "Too many open files". This happens during the Java build. Where is the limit set in jail? /etc/login.conf doesn't have any limit. What to do in such case? Maybe there is some way to tell Java to limit the number of open files? Yuri I would take a look at /usr/local/etc/poudriere.conf at the MAX_FILES setting. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] Why FreeBSD ports should have branches by OS version
On Jun 23 08:02, scratch65...@att.net wrote: On Fri, 23 Jun 2017 00:36:19 +0200, Miroslav Lachman <000.f...@quip.cz> wrote: scratch65...@att.net wrote on 2017/06/23 00:15: [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon wrote: On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote: My problem is that my industry experience tells me that reducing the frequency of port releases is practically *guaranteed* to be a Really Good Thing for everyone. I remember before we had the quarterly releases, and people on the mailing lists complained constantly about the ports bits only being available once per release, or rolling with -head. Mark, I can only suppose that those complainers are dilettantes of some sort who believe that having The Latest-And-Greatest Bits is a social-status enhancer. **Nobody** with real work to do ever willingly fools away time "fixing" what isn't broken. And this is where you are so wrong. Ports tree is never in the state where everything works and has no bugs. (and cannot be, because upstreams have bugs) Even if it compiles and installs it does not mean that it is not broken and nobody needs newer version. Just because your needs are different than others doesn't mean others are dilettantes. How often have you bought all new versions of the software you use, Miroslav, even though the versions you replaced still worked fine? I'd bet that you've never done that, and never will: you're an adult, and have more important uses for your time and money. How often do you look around your flat or house for something to "fix" even though everthing works well enough? I'd bet not often, if ever -- you probably always have so much real work to do that you worry you'll never get it all done if you live to be 120. There are individuals who claim to "need" the latest Mercedes or Ferrari, or a bigger yacht, or a chalet in Switzerland. But that kind of "need" isn't on the same level as someone's need for a place to live, or a way to get to work, or medical care for their kids. Similarly, few people constantly "need" the latest software. Even if the new release has a feature that will make their work easier, the release after that one is not likely to have *another* such feature. Nearly all adults can do their computer-based work just fine without ever having the Latest-And-Greatest hardware and software. Those who claim they simply *must* always have bleeding-edge kit are kidding someone. Or delusional. ___ Can we stop suggesting that everybody in the world wants a stable release that doesn't frequently change, or that people who want to use the latest versions of software are delusional please? I use FreeBSD *precisely* because it mostly keeps up with the latest stable versions of things. I have postfix 3.2, pgsql 9.6, nginx 1.13, libressl 2.5 etc. It's usually impossible to do this with linux unless you install things directly from source. I upgrade my ports/packages via poudriere every single day which mostly just takes 2 minutes of my time as usually that results in maybe one or two packages being updated at a time. I see this as a positive thing rather than doing one massive huge upgrade every 3 months. If I see that a package is going to have a major version upgrade then I say no and cancel the update until I have a spare half hour or so later in the day. Then I will spend the time seeing what the differences are and changing my config etc as appropriate. I actually like this way of working and it suits me fine. I enjoy learning the ins and outs of new software. If everybody had the attitude of never spending time doing major version updates then we would all be in the python3 verses python 2 situation where virtually nobody is writing python3 code. I'm not going to argue against what you guys are asking for, each to their own, you have your own requirements and that's fair enough. But I just wanted to make a point that the way that FreeBSD currently does it is not "nobody wants it done this way". At least one person does thanks. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Keeping -CURRENT up to date with Poudriere
On Jun 19 23:14, Jaap Akkerhuis wrote: On Jun 19, 2017, at 20:24, Ben Lavery-Griffiths wrote: Thanks very much, I’ll look into doing similar. What I do is to have STABLE and CURRENT jails using the svn method. Then "poudriere jail -u" takes care of the update. Why bother having the system compile it twice? If you use -m src=/usr/src then it will just use the already built STABLE world from your host build. Easy way to make it synced to the live system. And poudriere jail -u still works fine to update it. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The ports collection has some serious issues
On Dec 08 05:16, Daniil Berendeev wrote: Although portmaster is not releated to the FreeBSD project and is an outside tool, there aren't any alternatives from the project itself. So use it or die. Not a nice situation. People have been trying to get portmaster deprecated and removed from the handbook but have met with resistance. It's pretty much unmaintained and because it acts on a live system can mess up as it has no idea if a port needs recompiling because a dependency changed ABI etc. The recommended replacements are ports-mgmt/synth and ports-mgmt/poudriere. These build an entire package repository that the pkg tool can use but they do so in clean chrooted environments, and rebuild everything that's required to keep a consistent ABI. Synth is more designed for a single live system like a desktop or a single server, whereas poudriere is what the freebsd package build clusters use and is more designed for that type of usage. Worth taking a look. It's a shame the handbook hasn't been updated to give this information. Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: lighttpd does not pull OpenSSL dependency
On Oct 27 16:22, Matt Smith wrote: I don't see this on my system which is FreeBSD 11.0-STABLE #0 r307132 $ ldd /usr/local/sbin/ntpd | grep -E '(crypto|ssl)' libcrypto.so.38 => /usr/local/lib/libcrypto.so.38 (0x800cee000) libssl.so.39 => /usr/local/lib/libssl.so.39 (0x801aca000) Oh never mind, I guess it's because the so revision is 38/39 whereas in openssl it's 8 the same as the base version. Sorry for the noise! -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: lighttpd does not pull OpenSSL dependency
On Oct 27 10:00, Matthew D. Fuller wrote: On Thu, Oct 27, 2016 at 03:05:03PM +0200 I heard the voice of Mathieu Arnold, and lo! it spake thus: Once you install openssl from ports, the ports framework will use it, always. That is absolutely not the case since OpenSSL in base was updated to .so.8 and ports wasn't re-bumped past it. Everything gets confused all the time. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209582 Even in an e.g. net/ntp rebuilt just now: % ldd /usr/local/sbin/ntpd | grep -E '(crypto|ssl)' libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x800cea000) libssl.so.8 => /usr/lib/libssl.so.8 (0x801ae6000) Just looking at a ldd through /usr/local I'm finding tons of things that are still linking to base libcrypto. STuff from ldns, nginx, Virtualbox, libwww, lots of X pieces... This makes me *EXTREMELY* nervous about upgrading _any_ systems where I'm using ports OpenSSL to stable/11. I don't see this on my system which is FreeBSD 11.0-STABLE #0 r307132 $ ldd /usr/local/sbin/ntpd | grep -E '(crypto|ssl)' libcrypto.so.38 => /usr/local/lib/libcrypto.so.38 (0x800cee000) libssl.so.39 => /usr/local/lib/libssl.so.39 (0x801aca000) Most likely because I have correctly declared the default version of the SSL library by putting DEFAULT_VERSIONS=ssl=libressl-devel in make.conf. Without declaring it specifically like that I wouldn't trust the system to do it automatically either. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Upcoming OpenSSL 1.1.0 release
On Aug 24 21:18, Bernard Spil wrote: Today new vulnerabilities with (3)DES and BlowFish were made public and I believe we'll see release of another paper which is OpenSSL 1.1 related with the release of OpenSSL 1.1.0. I have no knowledge if the paper/report contained vulnerabilities that have postponed the release of 1.1.0 but I think that is likely. That would mean that these vulnerabilities have been solved pre-release. As far as I know x25519 is still a Draft RFC so unlikely to appear in browsers for a while. I can see LibreSSL adding this as well, whether in the draft version or in the final. This they did with ChaCha20/Poly1305 as well (draft in 2.3, release in 2.4). The LibreSSL devs would have closed the request if they didn't intend to support it https://github.com/libressl-portable/portable/issues/114 I don't think that FreeBSD will be making LibreSSL the libssl/libcrypto provider any time soon. The support timelines for LibreSSL (<1.5 years) are just too short for the FreeBSD release support (>3 years). OpenSSL is speeding up the release cycle as well but at least we can rely on RedHat to backport changes to older versions. LibreSSL in base is a bit more than playing, it is becoming the default in HardenedBSD very soon and very likely in TrueOS (AKA PC-BSD) as of 11.0 RELEASE. Both HardenedBSD and TrueOS have a different attitude towards updating things in the base system as they do not serve as upstream to other projects/products that require longer support timelines. Come see my talk at EuroBSDCon, it will contain LibreSSL in base things. Cheers, Bernard. Thanks for that reply. That answers things quite nicely. I believe x25519 is currently in chrome: https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=51&platform=Win%207&key=126 It has x25519 listed as an Elliptic curve near the bottom. So for that reason I am interested in enabling it as I like to do things bleeding edge! I will probably stick with security/libressl-devel for the foreseeable future though I think and at least wait and see what people make of OpenSSL 1.1 after a few months if only for the fact it's a bit of a pain to switch back again by recompiling everything. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Upcoming OpenSSL 1.1.0 release
On Aug 23 12:19, Roger Marquis wrote: Matt Smith wrote: Going slightly off-topic, I'm curious what the opinion is around this and LibreSSL. My organization evaluated this a few months ago and after a few diffs and code reviews decided that libressl was the future. We updated poudriere and all make.confs, removed openssl, installed libressl and have had no issues. We did the same with openntp a few months earlier and recommend both for any installation that needs good security. Roger I have been running libressl-devel for the past few months and other than having to manually patch a few ports to get them to compile have also had no problems. However this was the case a few months ago. My questioning is specifically related to the upcoming OpenSSL 1.1 which in theory has had a lot of work done to it by a full-time paid team of developers. In fact it was meant to be released back in May but was delayed specifically so that they could squash all remaining bugs. It would be interesting if somebody could audit the changes to see how it compares to LibreSSL after it's released. There is a possibility that it may actually be the better path going forward. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Upcoming OpenSSL 1.1.0 release
On Aug 22 20:39, Mathieu Arnold wrote: ports-committers is a *NEVER POST DIRECTLY TO* list, so, moving it to ports@ where this belongs a lot more. +--On 22 août 2016 20:30:15 +0200 Bernard Spil wrote: | Curious to know how we should procede with the upgrade of the OpenSSL | port to 1.1.0! All ports need to work with it, I'm sure software like BIND9 do not build with it. -- Mathieu Arnold Going slightly off-topic, I'm curious what the opinion is around this and LibreSSL. My understanding is that LibreSSL was forked from OpenSSL 1.0.1 and they have not backported newer stuff from OpenSSL. I also believe OpenSSL now has several full time paid developers working on it and that the 1.1 release has some significant changes under the hood? I've been using LibreSSL for a while so that I can get chacha20 support but OpenSSL 1.1 will not only have chacha20, but will also have x25519 support as well. This along with what I said above is making me think it might be better to go back to OpenSSL. I just wondered what people in the know think about the current situation with these two things. Plus are there any roadmaps for the future of FreeBSD regarding the defaults. Is the project ever going to look at making LibreSSL the default port, or will that be kept as OpenSSL for many years to come? I know Bernard has been looking into that and playing around with LibreSSL in base etc. Just curious what the official policy is going to be on that. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg updating -d broken?
On May 26 21:53, Alphons van Werven wrote: Matt Smith via freebsd-ports wrote: Anybody else notice that pkg updating -d has been broken for a while? Or is it just me? # grep 2016 /usr/ports/UPDATING | head -4 20160526: 20160525: 20160523: 20160511: # pkg updating -d 20160523 Just to be sure: you do know that "pkg updating" only displays UPDATING entries for ports that you have actually installed, right? AvW Wow, no I did not actually know that! Now I re-read the man page you're right, it clearly says that. It's just that whenever I've ran this command in past months it has *always* shown some entries whereas in the past month or two I've never seen it output anything at all. So it looked strange to me. It makes sense now though, thanks! -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
pkg updating -d broken?
Anybody else notice that pkg updating -d has been broken for a while? Or is it just me? # grep 2016 /usr/ports/UPDATING | head -4 20160526: 20160525: 20160523: 20160511: # pkg updating -d 20160523 # -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: mail/postfix and mail/postfix-current need upgrading
On Feb 26 18:48, olli hauer wrote: In some weeks 3.1.x will become the default postfix, and 3.0.x will be removed from the tree, postfix211 will stay as the last postfix 2.x releases and current will become again current. There are some users using VDA patches, only available for postfix 2.8 but it also works on 2.11, there is no support from the VDA project for 3.x and it seems the VDA project is no longer alive. I saw this in the updates that you made yesterday, thanks! However it looks like VDA is still in the Makefile for postfix-current which seems weird if you say that you have removed VDA support? -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP7 + Synth issue
On Feb 17 15:05, Kurt Jaeger wrote: Hi! > The long term solution will be switching to mysqli or pdo_mysql which is > provided by php70 (and php55/56), I am working right now on cleaning up > the pecl ports, after that I'll go and check which port can switch already. The problem with that approach is that his tree is broken now. His choice is don't build at all or don't use php 7.0. I think it's something that needs attention now unless the intent is to say, "don't use php7 yet, it is not ready for prime time" (which is possible) The PHP eco-system is so huge that one can say that even php56 is not yet ready for prime time 8-) So: Everyone knows that php70 has open issues, miwi and others are tracking them down, and if users/testers submit problem reports via bugzilla, it helps enormously. It will settle the next few weeks. I'll search bugzilla to see if there are any bug reports for this and if not I'll raise one then. I know php70 is very new so I was expecting problems. Synth is pretty new as well though so I thought I would let people know in case they were not aware of this type of breakage. Thanks, -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PHP7 + Synth issue
On Feb 17 14:16, John Marino wrote: It seems like a problem with comms/atslog to me. You can work around it now by removing MYSQL as a default option for that port (either modifying the port itself or adding something in -make.conf to change it) atslog is not maintained. Another option is hiding the option if php>=7. Probably the easiest thing to do is turn off the option by default though. The problem is that it isn't just that port. I've also seen it on databases/mysqldumper for example. It's going to affect all ports which have USE_PHP=mysql within them of which I suspect there are quite a lot. It might be impractical to do what you suggest with them all and I'm wondering if miwi as the maintainer of PHP7 has any thoughts of an official way of solving it. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
PHP7 + Synth issue
Hi guys, I'm using the ports-mgmt/synth package builder to build my packages. I just tried to build all of the packages for PHP7 from the new ports and came across an issue. If I set php=7.0 in DEFAULT_VERSIONS in the LiveSystem-make.conf (make.conf) then Synth bails out and refuses to build the repository. It does this: Scanning entire ports tree. progress: 5.93% culprit: comms/atslog Scan aborted because dependency could not be located. databases/php70-mysql (required dependency of comms/atslog) does not exist. It looks like it scans the port tree, come across a port that has USE_PHP=mysql in it and then bails because the port databases/php70-mysql does not exist. Obviously because mysql was removed from PHP7 in favour of mysqli. Is this a problem with the ports infrastructure or should I just not declare php=7.0 in the DEFAULT_VERSIONS? If I do this then it builds fine, but I guess that might cause other issues elsewhere. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
On Feb 11 22:25, Lev Serebryakov wrote: On 07.02.2016 17:28, John Marino wrote: ports-mgmt/synth. I would love to hear what signficant thing portmaster can do that Synth can't. (honestly) Be installed FROM PORTS without all this build-one-more-gcc stuff. Ada? For *port*management* tool? Are you joking? -- // Lev Serebryakov Remember that before portmaster we had cvsup which was written in Modula-3 and portupgrade which is written in Ruby. Whilst it is nice that portmaster is just a simple shell script with no dependancies that's a relatively new thing. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Removal of $UNIQUENAME
On Aug 18 22:49, Kimmo Paasiala wrote: It would have been nice to have some kind of announcement about the removal of $UNIQUENAME. I for example was depending on it in my make.conf with declarations like these: vim_SET= CONSOLE vim_UNSET= GTK2 RUBY TCL I can of course rewrite those now using $OPTIONS_NAME (editors_vim prefix instead of vim) after reading bsd.option.mk and figuring out the way that works... -Kimmo There was. "pkg updating UNIQUENAME" will show you the announcement. Or just look at the top of /usr/ports/UPDATING. -- Matt ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: OpenSSL Security Advisory [11 Jun 2015]
On Jun 13 13:13, Michelle Sullivan wrote: Don Lewis wrote: On 13 Jun, Michelle Sullivan wrote: SSH would be the biggie that most security departments are scared of... Well, ssh is available in ports, though I haven't checked to see that it picks up the correct version of openssl. Problem is it doesn't have 'overwrite base' anymore - and openssh-portable66 which does have overwrite base is now marked depreciated... which means one would have to be very careful about how they use SSH in production as both server and client... Server is easier as it has a different _enable identifier... but the client is not distinguishable so unless one puts /usr/local/bin in their permanent path as a priority over /usr/bin one will use the wrong version. I put WITHOUT_OPENSSH=yes in /etc/src.conf. Then run make delete-old and make delete-old-libs in /usr/src. This removes the base version which means you don't have this issue any longer. I do the same thing with NTP and Unbound as well. Obviously this makes more sense if like me you do source based stuff rather than using freebsd-update. I'm not sure if you can do similar with binary based upgrades? The other alternatives are as you say, put /usr/local/bin before /usr/bin in the $PATH. Or add an alias for commands like ssh to point to the ports version. These methods aren't quite as clean though. -- Matt ___ 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"
ports/base ntpd rc.d script with WITHOUT_NTP=yes
Hi, I just upgraded my server to 10.1-STABLE r281264 and when I ran mergemaster it told me that /etc/rc.d/ntpd was stale and would I like to delete it. It's never done this before. I've figured out it's because I have WITHOUT_NTP=yes in /etc/src.conf. I did this because I use the ports version of ntpd and thus wanted to remove the base installed version so that when I run commands like ntpq it's using my possibly newer port installed version and not the older one. However, the port version doesn't have its own rc script. It usually uses the base version with ntpd_program and ntpd_config set. With this latest change it means I have to have the base version installed again. Is it possible to get the port version to have its own rc script? -- Matt ___ 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: Broken port: handbrake
Thanks for the response. I did just run "portsnap fetch && portsnap extract" right before trying. Why wouldn't I be at the latest version of the ports tree? Also, do I understand you correctly that even if I were using the latest ports, the handbrake port would still be broken? Any suggestions for how I could fix it manually? Thanks, Matt > On Mar 21, 2015, at 9:28 PM, Matthew Donovan wrote: > > > On Mar 21, 2015 8:21 PM, "Matt Klein" wrote: > > > > Hello, > > > > I'm having a problem with the port "handbrake". > > > > From the Makefile: > > # Created by: Andrew Thompson > > # $FreeBSD: head/multimedia/handbrake/Makefile 374303 2014-12-08 16:48:38Z > > tijl $ > > > > The build and install of the port succeeds, but the resulting installation > > is broken. Attempting to read a DVD leads to this error: > > > > # HandBrakeCLI -t 1 -f mp4 -e x264 -q 20 -E faac -B 160 -i /dev/cd0 -o > > /tmp/out.mp4 > > [21:03:28] hb_init: starting libhb thread > > HandBrake rev5474 (2015032199) - FreeBSD amd64 - http://handbrake.fr > > 4 CPUs detected > > Opening /dev/cd0... > > [21:03:28] hb_scan: path=/dev/cd0, title_index=4 > > libbluray/bdnav/index_parse.c:162: indx_parse(): error opening > > /dev/cd0/BDMV/index.bdmv > > libbluray/bdnav/index_parse.c:162: indx_parse(): error opening > > /dev/cd0/BDMV/BACKUP/index.bdmv > > libbluray/bluray.c:1725: nav_get_title_list(/dev/cd0) failed (0x8048b3000) > > [21:03:28] bd: not a bd - trying as a stream/file instead > > libdvdnav: Using dvdnav version 4.1.3 > > libdvdread: Missing symbols in libdvdcss.so.2, this shouldn't happen ! > > libdvdread: Using libdvdcss version for DVD access > > Segmentation fault > > > > From these links: > > > > https://bbs.archlinux.org/viewtopic.php?id=187410 > > http://www.linuxquestions.org/questions/slackware-14/handbrake-and-current-4175528049/ > > > > It looks this is due to a handbrake bug that was fixed in version 0.9.9-8; > > I'm guessing that the version installed by the port is earlier than this, > > but I don't know enough about how the ports system works to be able to say > > definitively or to fix it myself. > > > > I'm using FreeNAS version 9.3. > > # uname -i -K -r -U -v > > 9.3-RELEASE-p10 FreeBSD 9.3-RELEASE-p10 #0 r275790+c9242cc: Mon Mar 16 > > 12:46:11 PDT 2015 > > r...@build3.ixsystems.com:/tank/home/nightlies/FN93/objs/os-base/amd64/tank/home/nightlies/FN93/FreeBSD/src/sys/FREENAS.amd64 > > FREENAS64 903000 903000 > > > > Any assistance would be greatly appreciated! > > > > Thanks, > > Matt Klein > > ___ > > 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" > > Your ports are out of date the lastest port is 9.9.3. The port does need to > be updated to the latest however. Which I cant do currently as not near a > FreeBSD system currently ___ 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"
Broken port: handbrake
Hello, I'm having a problem with the port "handbrake". >From the Makefile: # Created by: Andrew Thompson # $FreeBSD: head/multimedia/handbrake/Makefile 374303 2014-12-08 16:48:38Z tijl $ The build and install of the port succeeds, but the resulting installation is broken. Attempting to read a DVD leads to this error: # HandBrakeCLI -t 1 -f mp4 -e x264 -q 20 -E faac -B 160 -i /dev/cd0 -o /tmp/out.mp4 [21:03:28] hb_init: starting libhb thread HandBrake rev5474 (2015032199) - FreeBSD amd64 - http://handbrake.fr 4 CPUs detected Opening /dev/cd0... [21:03:28] hb_scan: path=/dev/cd0, title_index=4 libbluray/bdnav/index_parse.c:162: indx_parse(): error opening /dev/cd0/BDMV/index.bdmv libbluray/bdnav/index_parse.c:162: indx_parse(): error opening /dev/cd0/BDMV/BACKUP/index.bdmv libbluray/bluray.c:1725: nav_get_title_list(/dev/cd0) failed (0x8048b3000) [21:03:28] bd: not a bd - trying as a stream/file instead libdvdnav: Using dvdnav version 4.1.3 libdvdread: Missing symbols in libdvdcss.so.2, this shouldn't happen ! libdvdread: Using libdvdcss version for DVD access Segmentation fault >From these links: https://bbs.archlinux.org/viewtopic.php?id=187410 http://www.linuxquestions.org/questions/slackware-14/handbrake-and-current-4175528049/ It looks this is due to a handbrake bug that was fixed in version 0.9.9-8; I'm guessing that the version installed by the port is earlier than this, but I don't know enough about how the ports system works to be able to say definitively or to fix it myself. I'm using FreeNAS version 9.3. # uname -i -K -r -U -v 9.3-RELEASE-p10 FreeBSD 9.3-RELEASE-p10 #0 r275790+c9242cc: Mon Mar 16 12:46:11 PDT 2015 r...@build3.ixsystems.com:/tank/home/nightlies/FN93/objs/os-base/amd64/tank/home/nightlies/FN93/FreeBSD/src/sys/FREENAS.amd64 FREENAS64 903000 903000 Any assistance would be greatly appreciated! Thanks, Matt Klein ___ 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: BIND REPLACE_BASE option
On Jan 14 13:30, Michelle Sullivan wrote: Matt Smith wrote: Doug Barton who used to maintain BIND in both the base system and the port used to always say that the version in the base system was only designed to be used as a local resolver on a laptop/desktop. If it was used as a proper DNS server the port version was meant to be used instead. Based on this it makes perfect sense why BIND was replaced with local Unbound in the base, and the ports system still has BIND for people that were using it. Was this ever documented? (I've been using bind in base for servers for many years and this is the first time I've heard of it - and it is unlikely I'm the only one.) I'm not sure if it was documented anywhere in particular. I've just seen it mentioned lots of times on these mailing lists in the past. Specifically around the time he was experimenting with slaving the root and arpa zones and there were a few configuration changes to named.conf at that time. The main reasoning is that the versions of things in the base system are usually old and rarely get updated. They occasionally get patches if there's a serious security vulnerability but for minor bugs it's unlikely you'll see any patch. And to patch it you quite often need to do a full O/S upgrade which is very time consuming and probably needs a reboot. The port versions are updated straight away, even for minor bugs and because you've not also updated half the O/S in the process you don't need to do anything other than restart named. -- Matt ___ 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: BIND REPLACE_BASE option
On Jan 14 12:15, Mathieu Arnold wrote: Well, like I said, REPLACE_BASE was an abomination that should never have existed, now that it's gone, it'll never get back, and you'll never see it again. Doug Barton who used to maintain BIND in both the base system and the port used to always say that the version in the base system was only designed to be used as a local resolver on a laptop/desktop. If it was used as a proper DNS server the port version was meant to be used instead. Based on this it makes perfect sense why BIND was replaced with local Unbound in the base, and the ports system still has BIND for people that were using it. It should have been a very small minor change. If people didn't want to have two versions installed then the solution would have been to use WITHOUT_NAMED or WITHOUT_BIND whatever the knob was in src.conf so that those files were deleted or not installed in the first place. I do exactly this for NTPd, OpenSSH, and Unbound all of which I use the port versions for so don't need them in the base system. -- Matt ___ 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: gnupg-2.1 -> 2.1 appears to break decryption of saved messages
On Jan 07 07:49, Corey Halpin wrote: On 2014-11-20, David Wolfskill wrote: It has been my practice for several years to email sensitive information (such as passwords) to myself via envrypted email, using mutt and GPG. [...] Then, a few minutes ago, I tried to retrieve a password from one of my saved encrypted messages... only to be informed "Could not copy message". I also enjoyed some friction trying to use gnupg 2.1 with mutt, though I didn't get the "Could not copy message" error that you report. Instead I was seeing 'no secret key'. In my case, this was resolved by following the advice at https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase . Namely: echo allow-loopback-pinentry >> ~/.gnupg/gpg-agent.conf and editing my copy of mutt's gpg.rc to add '--pinentry-mode loopback' to every gpg invocation involving a passphrase-fd. After that, things were back to normal for me. Hopefully this helps others avoid the same problem. ~crh I also had exactly the same problems, not only with mutt but with duplicity. I figured out how to fix it from the same site you found. This is very useful information which should have really been in the gpg release notes. However I also found that with this new version of gpg there is a better way to fix it. If you install the security/gpgme port then you don't need any of the gpg.rc stuff at all. You can replace it all with a single line of configuration "set crypt_use_gpgme=yes". Then it uses a much more sane internal API or something rather than parsing external commands. -- Matt ___ 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: gnupg & pinentry
On Dec 23 07:44, Mark Felder wrote: It looks as though it would be feasible to write an extremely lightweight pinentry-compatible program to depend on so we can kill the dependency bloat and have a simple shell-based password entry option. Anyone up for a weekend challenge? :-) There has been another thread on this mailing list discussing making the port honour the WITHOUT_X11 and OPTIONS_UNSET+=X11 options from make.conf which would make it only depend on security/pinentry-curses instead of security/pinentry. This seems like a good solution to me. It would mean if one of those options is set it will only drag in a single dependancy rather than all the X11 libraries and GTK. -- Matt ___ 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: gnupg & pinentry
On Dec 22 22:33, Jonathan Chen wrote: Hi, Once upon a time, installing gnupg didn't require pinentry, and I could run it quite happily on the command line. However, nowadays if I install the port it drags in pinentry and a whole set of graphical libraries that I don't really need on a headless box. Is pinentry really required for gnupg to run correctly? I believe in version 2.1.x they made entering the passphrase via pinentry basically mandatory and deprecated being able to do it via stdin methods. So it probably pulls in pinentry by default now. For binary packages this is unfortunatly going to default to all the front ends which includes ones for X. For port based source installs you can deselect the ones for X and only leave the ncurses one which then just pulls in one extra dependancy. Unfortunately that's the downside of binary package installs. FYI, you can also re-enable passphrases by stdin if required by adding allow-loopback-pinentry to .gnupg/gpg-agent.conf and using the --pinentry-mode=loopback command line switch to gpg. -- Matt ___ 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: Unbound/NSD rc startup order
On Dec 12 12:07, Mathieu Arnold wrote: +--On 12 décembre 2014 05:00:00 -0600 Scot Hetzel wrote: | On Fri, Dec 12, 2014 at 4:15 AM, Darren Pilgrim | wrote |> On 12/11/2014 11:53 PM, Matt Smith wrote: |>> |>> Somebody has let me know that I made an obvious mistake in the above. I |>> meant that the default rcorder is to run Unbound first followed by NSD. |>> So to clarify I think in the default situation Unbound starts first, |>> contacts NSD and gets no answer because it hasn't been started yet and |>> then fails in some way. Whereas if NSD is running first then Unbound is |>> happy. |> |> |> Unbound requires SERVERS, but nsd requires LOGIN, a much later |> checkpoint. |> |> The fix would be adding an rcorder override mechanism whereby one could |> specify additional constraints (like unbound REQUIRE nsd). If there's |> interest for this, I can see about a patch. |> | Would it be better to add: | |# BEFORE: unbound | | to the dns/nsd rc.d script? Well, the thing is, a resolver is required way before an authoritative server is. Yes. I've been thinking that maybe it's actually in the correct order really after all. I've worked around my particular problem by changing the order, but that might not be the case for everyone else. I'm thinking now why actually do I have DNSSEC validation on my local intranet domain and reverse DNS anyway? I run two instances of NSD, one for the LAN which Unbound talks to, and one for the internet which everyone else talks to. It could be argued that I only need to DNSSEC sign the internet copies of the zones and not the LAN ones in which case this problem won't exist. Maybe I should just go down that route instead. -- Matt ___ 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: Unbound/NSD rc startup order
On Dec 11 10:51, Matt Smith wrote: Hi, I have run Unbound and NSD for a long time and everything was working fine until the recent 1.5.x update for Unbound. Now if I reboot my server I get DNSSEC validation errors for my own local domain until I restart Unbound once again. I believe this is possibly related to the rc startup order. My setup is that I have my local domain as an authoritative DNSSEC signed zone in NSD and then I use a stub-zone in Unbound which points to the NSD instance. I also hard-wire the DNSSEC key for this domain into Unbound using a trust-anchor-file declaration. When I rebooted my server last night this domain was failing validation with this error: info: validation failure : no DNSKEY rrset for trust anchor example.com. while building chain of trust If I restart unbound again then it works fine. The default rcorder is to start Unbound first followed by Unbound. I'm wondering if since 1.5.x Unbound now attempts to read some data from the stub-zone which fails because NSD isn't running but then when I restart it it works successfully? As a test I added nsd as a REQUIRE in the unbound rc.d script, rebooted again, and saw that it successfully worked as it did before I upgraded. It could just be an unrelated coincidence, but if it isn't I'm thinking the default rc order should maybe be changed for these ports? Somebody has let me know that I made an obvious mistake in the above. I meant that the default rcorder is to run Unbound first followed by NSD. So to clarify I think in the default situation Unbound starts first, contacts NSD and gets no answer because it hasn't been started yet and then fails in some way. Whereas if NSD is running first then Unbound is happy. -- Matt ___ 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"
Unbound/NSD rc startup order
Hi, I have run Unbound and NSD for a long time and everything was working fine until the recent 1.5.x update for Unbound. Now if I reboot my server I get DNSSEC validation errors for my own local domain until I restart Unbound once again. I believe this is possibly related to the rc startup order. My setup is that I have my local domain as an authoritative DNSSEC signed zone in NSD and then I use a stub-zone in Unbound which points to the NSD instance. I also hard-wire the DNSSEC key for this domain into Unbound using a trust-anchor-file declaration. When I rebooted my server last night this domain was failing validation with this error: info: validation failure : no DNSKEY rrset for trust anchor example.com. while building chain of trust If I restart unbound again then it works fine. The default rcorder is to start Unbound first followed by Unbound. I'm wondering if since 1.5.x Unbound now attempts to read some data from the stub-zone which fails because NSD isn't running but then when I restart it it works successfully? As a test I added nsd as a REQUIRE in the unbound rc.d script, rebooted again, and saw that it successfully worked as it did before I upgraded. It could just be an unrelated coincidence, but if it isn't I'm thinking the default rc order should maybe be changed for these ports? -- Matt ___ 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: Why was ispell removed?
On Dec 01 13:58, Stephen Fisher wrote:
> I recently noticed that the ispell port has been removed in favor of the
> aspell-ispell port ("ispell compatibility script for aspell"). Does
> anyone know why it was removed? All I see on Fresh Ports is that it
> was deprecated and finally removed in January of this year.
>
> (The ispell script for aspell doesn't fully replicate ispell
> functionality such as checking words on the command line as shown below)
>
> Real ispell:
> >ispell
> @(#) International Ispell Version 3.3.02 12 Jun 2005
> word: word
> ok
>
>
> word: ^D
>
>
>
> aspell script:
> >ispell
> Ispell compatibility script for Aspell.
> Usage: /usr/local/bin/ispell [options] -a|-l|-v[v]|-c|-e[1-4]|
It seems that you can just use the -a switch on aspell:
$ aspell -a
@(#) International Ispell Version 3.1.20 (but really Aspell 0.60.6.1)
helo this is a tset
& helo 11 0: he lo, he-lo, hello, helot, help, halo, hell, held, helm,
hero, he'll
*
*
*
& tset 5 15: test, stet, Set, Tet, set
It seems to do exactly the same as hunspell like you have been pointed
to in the rest of this thread?
--
Matt
___
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: Question about ports config dialog
Ah, thanks. Matt On Wed, Oct 1, 2014 at 8:17 AM, Matthew Seaman wrote: > On 10/01/14 16:01, Matt Reimer wrote: > > What does the "+" mean in the config dialogs that appear while building > > ports? Does it indicate a setting that's checked by default, or a > > recommendation, or ...? > > It means it's a new OPTION that has been added since the last time you > ran the config dialogue for that port, and hence one that you might want > to pay special attention to. The setting shown will be the default value. > > Cheers, > > Matthew > > > > ___ 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"
Question about ports config dialog
What does the "+" mean in the config dialogs that appear while building ports? Does it indicate a setting that's checked by default, or a recommendation, or ...? Thanks for your help. Matt ___ 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"
Switching from building ports to packages
I'd like to switch from building everything from source using ports to using packages as much as possible. This requires identifying which ports I'm currently building use the same port knobs as the binary packages that FreeBSD builds. Is there an easy way of showing how my port configs differ from the defaults that are used to build binary packages? Thanks in advance. Matt ___ 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 Port: graphics/GraphicsMagick
Hello,
I am attempting to update to the latest graphics/GraphicsMagick port. The build
succeeds, but staging fails and I have not been able to find a way to make it
work. Below is the output of the stage command.
-- m@
# uname -a
FreeBSD x24.msqr.us 9.2-RELEASE-p7 FreeBSD 9.2-RELEASE-p7 #0: Tue Jun 3
11:05:13 UTC 2014
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
[/usr/ports/graphics/GraphicsMagick]# make stage
===> Staging for GraphicsMagick-1.3.19_1,1
===> GraphicsMagick-1.3.19_1,1 depends on file:
/usr/local/libdata/pkgconfig/xext.pc - found
===> GraphicsMagick-1.3.19_1,1 depends on file:
/usr/local/libdata/pkgconfig/xt.pc - found
===> GraphicsMagick-1.3.19_1,1 depends on executable: gs - found
===> GraphicsMagick-1.3.19_1,1 depends on shared library: libjbig.so - found
(/usr/local/lib/libjbig.so.2)
===> GraphicsMagick-1.3.19_1,1 depends on shared library: libjasper.so -
found (/usr/local/lib/libjasper.so.4.0.0)
===> GraphicsMagick-1.3.19_1,1 depends on shared library: libjpeg.so - found
(/usr/local/lib/libjpeg.so.11)
===> GraphicsMagick-1.3.19_1,1 depends on shared library: liblcms2.so - found
(/usr/local/lib/liblcms2.so.2.0.6)
===> GraphicsMagick-1.3.19_1,1 depends on shared library: libpng15.so - found
(/usr/local/lib/libpng15.so.15)
===> GraphicsMagick-1.3.19_1,1 depends on shared library: libtiff.so - found
(/usr/local/lib/libtiff.so.4)
===> GraphicsMagick-1.3.19_1,1 depends on shared library: libfreetype.so -
found (/usr/local/lib/libfreetype.so.6.11.2)
===> GraphicsMagick-1.3.19_1,1 depends on shared library: libwebp.so - found
(/usr/local/lib/libwebp.so.5.0.0)
===> GraphicsMagick-1.3.19_1,1 depends on shared library: libwmflite.so -
found (/usr/local/lib/libwmflite.so.7)
===> GraphicsMagick-1.3.19_1,1 depends on shared library: libdps.so - found
(/usr/local/lib/libdps.so.0.0.1)
===> GraphicsMagick-1.3.19_1,1 depends on shared library: libiconv.so.3 -
found (/usr/local/lib/libiconv.so.3)
===> GraphicsMagick-1.3.19_1,1 depends on shared library: libxml2.so - found
(/usr/local/lib/libxml2.so.2.9.1)
===> Generating temporary packing list
/usr/bin/make install-am
/bin/mkdir -p '/usr/ports/graphics/GraphicsMagick/work/stage/usr/local/lib'
/bin/sh ./libtool --mode=install /usr/bin/install -c -o root -g wheel
magick/libGraphicsMagick.la Magick++/lib/libGraphicsMagick++.la
wand/libGraphicsMagickWand.la
'/usr/ports/graphics/GraphicsMagick/work/stage/usr/local/lib'
libtool: install: /usr/bin/install -c -o root -g wheel
magick/.libs/libGraphicsMagick.so.14
/usr/ports/graphics/GraphicsMagick/work/stage/usr/local/lib/libGraphicsMagick.so.14
libtool: install: (cd
/usr/ports/graphics/GraphicsMagick/work/stage/usr/local/lib && { ln -s -f
libGraphicsMagick.so.14 libGraphicsMagick.so || { rm -f libGraphicsMagick.so &&
ln -s libGraphicsMagick.so.14 libGraphicsMagick.so; }; })
libtool: install: (cd
/usr/ports/graphics/GraphicsMagick/work/stage/usr/local/lib && { ln -s -f
libGraphicsMagick.so.14 libGraphicsMagick.so || { rm -f libGraphicsMagick.so &&
ln -s libGraphicsMagick.so.14 libGraphicsMagick.so; }; })
libtool: install: /usr/bin/install -c -o root -g wheel
magick/.libs/libGraphicsMagick.lai
/usr/ports/graphics/GraphicsMagick/work/stage/usr/local/lib/libGraphicsMagick.la
libtool: install: warning: relinking `Magick++/lib/libGraphicsMagick++.la'
libtool: install: (cd
/usr/ports/graphics/GraphicsMagick/work/GraphicsMagick-1.3.19; /bin/sh
/usr/ports/graphics/GraphicsMagick/work/GraphicsMagick-1.3.19/libtool --tag
CXX --mode=relink c++ -O2 -pipe -march=nocona -msse -msse2 -msse3
-fno-strict-aliasing -D_THREAD_SAFE -no-undefined -version-info 9:3:6
-L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -o
Magick++/lib/libGraphicsMagick++.la -rpath /usr/local/lib Magick++/lib/Blob.lo
Magick++/lib/BlobRef.lo Magick++/lib/CoderInfo.lo Magick++/lib/Color.lo
Magick++/lib/Drawable.lo Magick++/lib/Exception.lo Magick++/lib/Functions.lo
Magick++/lib/Geometry.lo Magick++/lib/Image.lo Magick++/lib/ImageRef.lo
Magick++/lib/Montage.lo Magick++/lib/Options.lo Magick++/lib/Pixels.lo
Magick++/lib/STL.lo Magick++/lib/Thread.lo Magick++/lib/TypeMetric.lo
magick/libGraphicsMagick.la -inst-prefix-dir
/usr/ports/graphics/GraphicsMagick/work/stage)
libtool: relink: c++ -fPIC -DPIC -shared -nostdlib /usr/lib/crti.o
/usr/lib/crtbeginS.o Magick++/lib/.libs/Blob.o Magick++/lib/.libs/BlobRef.o
Magick++/lib/.libs/CoderInfo.o Magick++/lib/.libs/Color.o
Magick++/lib/.libs/Drawable.o Magick++/lib/.libs/Exception.o
Magick++/lib/.libs/Functions.o Magick++/lib/.libs/Geometry.o
Magick++/lib/.libs/Image.o Magick++/lib/.libs/ImageRef.o
Magick++/lib/.libs/Montage.o Magick++/lib/.libs/Options.o
Magick++/lib/.libs/Pixels.o Magick++/lib/.libs/STL.o
Magick++/lib/.libs/Thread.o Magick++/lib/.libs/TypeMetric.o -Wl,-rpath
-Wl,/usr/local/lib -L/usr/local/lib
-L/usr/ports/graphics/GraphicsMagick/work/stage/usr/local/lib -lGraphicsMagick
Re: Maximizing the use of binary packages and minimizing building packages
That's good news. What should I watch for in order to know when Really Soon Now becomes Now? Matt On Tue, Jan 14, 2014 at 12:14 PM, Matthew Seaman wrote: > On 14/01/2014 18:52, Chris Rees wrote: > > Mixing ports and packages is discouraged and can get messy, because > > upgrades can get out of sync... > > Although with recent developments in pkgng, that advice is going to > become outdated Real Soon Now. > > It is already possible to use mostly binary packages but compile some > yourself. However, yes, it can get messy and you need to be careful > about keeping your build tree reasonably in synch with the tree used to > build the official ports. Also, ingeneral, it's much easier to build > your ports when they are at the end of the dependency chain; ie. with > nothing else that depends on them. > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. > PGP: http://www.infracaninophile.co.uk/pgpkey > > > ___ 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"
Maximizing the use of binary packages and minimizing building packages
I'd like to switch from installing and upgrading our packages using portmaster/portupgrade to using pkg + binary packages from the ports cluster as much as possible. I understand that the ports cluster builds its packages using default options, but some of our packages we need built with custom options (e.g. enable mysql for postfix). Is there a tool that can look at /var/db/ports/foo/options and tell which options differ from the default options? Then I could decide whether I can live with the defaults (and therefore use the binary package), or whether to pkg-lock that package and update it by hand using portmaster. Or is there a better way to handle this situation, where I want to use binary packages where possible and only build when necessary? Thanks for your help. Matt ___ 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"
Strange Package Configuration?
I recently was upgrading my FreeBSD systems, both host systems and jails, and all of a sudden came across a problem in the jail environments where it was attempting to create a package from the port. My jail environments have always had PACKAGE=/var/ports/packages in the /etc/make.conf file, but I just checked and none of my jail systems have ever had a /var/ports/packages. I'm trying to figure out what changed all of a sudden so I can make sure I'm accounting for it in my procedures... An example of the original error can be found at: http://resources.rock-pond.com/build.log /basejail/usr/ports is my R/O global ports tree for all jails, so I was confused as to why it wasn't using /var/ports/packages which was set in make.conf, then I noticed the directory wasn't there. I've been able to fix this, but I've never seen this in all my years, so just wondering what may have changed. Thanks for any info! Matt Lager -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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: SPAM: Re: No Response to Port Submission
I updated the PR with the pkg-plist diff Matthew Trisoline, System Engineer matt.trisol...@intermedix.com http://www.intermedix.com The information contained in this message is confidential and may be privileged and/or protected under law. If you received this message in error, please notify us immediately by forwarding a copy to complia...@intermedix.com and then deleting the original message and any attachments. From: olli hauer [oha...@gmx.de] Sent: Wednesday, January 23, 2013 14:45 To: freebsd-ports@freebsd.org Cc: Trisoline, Matt Subject: SPAM: Re: No Response to Port Submission On 2013-01-23 20:21, Trisoline, Matt wrote: > Hi Olli, > > I have updated the PR with an updated diff in the appropriate formate. I > would also be interested in becoming a maintainer of the port. > > Thanks, Hi Matthew, can you also provide your patches against the files dir? I just recognize your patch was shaped against a portsnap tree, therfore my first try against a svn tree failed. I can try to build the port on 8.3/9.1 (amd64) and if it builds commit your work and transfer maintainer to you. -- Regards, olli > > Matthew Trisoline, System Engineer > matt.trisol...@intermedix.com > http://www.intermedix.com > > The information contained in this message is confidential and may be > privileged and/or protected under law. If you received this message in > error, please notify us immediately by forwarding a copy to > complia...@intermedix.com and then deleting the original message and > any attachments. > > From: owner-freebsd-po...@freebsd.org [owner-freebsd-po...@freebsd.org] On > Behalf Of Michael Gmelin [free...@grem.de] > Sent: Wednesday, January 23, 2013 14:09 > To: freebsd-ports@freebsd.org > Subject: Re: No Response to Port Submission > > On Wed, 23 Jan 2013 19:56:20 +0100 > olli hauer wrote: > >> On 2013-01-23 17:34, Trisoline, Matt wrote: >>> Hello, >>> >>> I have submitted >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174620 to update >>> the Postgis port from version 1.5.3 to 2.0.2 to work with Postgres >>> 9.2. The original port maintainer has been unresponsive and I have >>> tried to contact the person that was assigned this from FreeBSD and >>> he has also been unresponsive. This port as it stands is slated to >>> be deleted from the ports tree at the end of this month. I >>> understand that there is a 3 month timeout on port maintainers, but >>> with it being slated for removal from the ports tree and the >>> unresponsiveness from the original maintainer if someone could take >>> a look at this and move it along in the process or provide me the >>> feedback that I need to get this moving forward. I would also like >>> to note that there are several other PRs that are awaiting feedback >>> from the original maintainer that are older than the one I >>> submitted. >>> >>> Other PRs Awaiting original Maintainer Feedback >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/167955 >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171849 >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174764 >>> >>> Thanks, >>> >> >> Hi Matthew, >> >> Are you interested in become the maintainer for postgis? >> I think this can be arranged. >> >> Also could you please update your PR 174620 with a patch taken in the >> opposite order diff -u $orig $new (instead $new $orig) >> else it is hard handwork to apply your patch. > > By "hard work" you mean using "patch -R" when applying it? > (see man patch) and look for reverse > > Just sayin'... ;) > >> >> -- >> Regards, >> olli >> ___ >> 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: No Response to Port Submission
Hi Olli, I have updated the PR with an updated diff in the appropriate formate. I would also be interested in becoming a maintainer of the port. Thanks, Matthew Trisoline, System Engineer matt.trisol...@intermedix.com http://www.intermedix.com The information contained in this message is confidential and may be privileged and/or protected under law. If you received this message in error, please notify us immediately by forwarding a copy to complia...@intermedix.com and then deleting the original message and any attachments. From: owner-freebsd-po...@freebsd.org [owner-freebsd-po...@freebsd.org] On Behalf Of Michael Gmelin [free...@grem.de] Sent: Wednesday, January 23, 2013 14:09 To: freebsd-ports@freebsd.org Subject: Re: No Response to Port Submission On Wed, 23 Jan 2013 19:56:20 +0100 olli hauer wrote: > On 2013-01-23 17:34, Trisoline, Matt wrote: > > Hello, > > > > I have submitted > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174620 to update > > the Postgis port from version 1.5.3 to 2.0.2 to work with Postgres > > 9.2. The original port maintainer has been unresponsive and I have > > tried to contact the person that was assigned this from FreeBSD and > > he has also been unresponsive. This port as it stands is slated to > > be deleted from the ports tree at the end of this month. I > > understand that there is a 3 month timeout on port maintainers, but > > with it being slated for removal from the ports tree and the > > unresponsiveness from the original maintainer if someone could take > > a look at this and move it along in the process or provide me the > > feedback that I need to get this moving forward. I would also like > > to note that there are several other PRs that are awaiting feedback > > from the original maintainer that are older than the one I > > submitted. > > > > Other PRs Awaiting original Maintainer Feedback > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/167955 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171849 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174764 > > > > Thanks, > > > > Hi Matthew, > > Are you interested in become the maintainer for postgis? > I think this can be arranged. > > Also could you please update your PR 174620 with a patch taken in the > opposite order diff -u $orig $new (instead $new $orig) > else it is hard handwork to apply your patch. By "hard work" you mean using "patch -R" when applying it? (see man patch) and look for reverse Just sayin'... ;) > > -- > Regards, > olli > ___ > 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" -- Michael Gmelin ___ 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"
No Response to Port Submission
Hello, I have submitted http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174620 to update the Postgis port from version 1.5.3 to 2.0.2 to work with Postgres 9.2. The original port maintainer has been unresponsive and I have tried to contact the person that was assigned this from FreeBSD and he has also been unresponsive. This port as it stands is slated to be deleted from the ports tree at the end of this month. I understand that there is a 3 month timeout on port maintainers, but with it being slated for removal from the ports tree and the unresponsiveness from the original maintainer if someone could take a look at this and move it along in the process or provide me the feedback that I need to get this moving forward. I would also like to note that there are several other PRs that are awaiting feedback from the original maintainer that are older than the one I submitted. Other PRs Awaiting original Maintainer Feedback http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/167955 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171849 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174764 Thanks, Matthew Trisoline, System Engineer matt.trisol...@intermedix.com http://www.intermedix.com The information contained in this message is confidential and may be privileged and/or protected under law. If you received this message in error, please notify us immediately by forwarding a copy to complia...@intermedix.com and then deleting the original message and any attachments. ___ 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"
devel/lua-sysctl broken with clang (patch)
===> Building for lua-sysctl-0.2
install -m 755 -d sysctl
cc -shared -soname lua_sysctl -O2 -pipe -fno-omit-frame-pointer
-fno-strict-aliasing -fno-omit-frame-pointer -Wall -Wextra -fPIC
`pkg-config --cflags lua-5.1` -o sysctl/core.so src/lua_sysctl.c
cc: error: no such file or directory: 'lua_sysctl'
*** [sysctl/core.so] Error code 1
Stop in /usr/ports/devel/lua-sysctl/work/lua-syscl-0.2.
*** [do-build] Error code 1
This fixes it:
--- Makefile.orig 2013-01-23 12:05:52.459795869 +
+++ Makefile2013-01-23 12:08:13.371029152 +
@@ -2,7 +2,7 @@
SODIR = sysctl
SOLIB = ${SODIR}/core.so
-LDFLAGS += -shared -soname ${SONAME}
+LDFLAGS += -shared -Wl,-soname,${SONAME}
CFLAGS += -Wall -Wextra -fPIC `pkg-config --cflags lua-5.1`
all: ${SOLIB}
--
Sorry for the following...
The information contained in this message is confidential and intended for the
addressee only. If you have received this message in error, or there are any
problems with its content, please contact the sender.
iCritical is a trading name of Critical Software Ltd. Registered in England:
04909220.
Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH.
This message has been scanned for security threats by iCritical.
www.icritical.com
___
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: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
On 10/12/12 00:54, Claude Buisson wrote:
On 10/12/2012 05:00, matt wrote:
I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of
"USE_GCC=any" to a port's Makefile, and then committed that change to
various ports. In most (but not all!) cases this will tell the port
"build with gcc instead of clang" (*) .
Why not USE_GCC ?= any for the poor guys like me who build (some)
ports with
USE_GCC=4.6 ?
For those users with CC installed as gcc (including -stable), this
patch should have no effect. Variations of combinations have been
heavily tested on pointyhat-west. If there are any regressions,
please
contact me.
Does this override setting CC explicitly in make.conf?
Sorry if it's a dumb question, not sure exactly the hierarchy of USE_GCC
vs CC in the make system.
Dumb as I am, I also wonder when I see that in multimedia/x264:
...
USE_GCC=any
...
.if ${PORT_OPTIONS:MGCC44}
USE_GCC?=4.4+
.endif
...
which seems to deny the intent of the GCC44 option
Sorry but I can not make the test at this present time
Matt
Claude Buisson
I tested, and can confirm two things. CC is overpowered by USE_GCC=any,
which means that I end up with no sse4a and limited support for my arch
(Opteron 4xxx) because I can't set a better -march/cputype than
opteron-sse3. As far as I know base gcc doesn't even support sse4a. This
is really perhaps an issue with me setting CC in make.conf moreso than
ports, however this was the approved method of using clang by default as
well as the approved method of using ports gcc in the ports system. Is
there a new approved method?
M. Buisson's test case also fails, with base gcc being used even though
the gcc44 option is chosen. This may not break as many ports as it
might, but it will certainly create low performing editions of many
multimedia ports given the CPU features supported by either later clang
or gcc. Some will probably break?
If I missed something, please let me know, or if my testing is somehow
compromised. I removed make.conf (as mine is customized) for Claude's
test case, but it's possible something else may have affected my test
results. USE_GCC=any was manually added to the ports makefiles (test
case was editors/nano and multimedia/x264).
Matt
___
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: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of "USE_GCC=any" to a port's Makefile, and then committed that change to various ports. In most (but not all!) cases this will tell the port "build with gcc instead of clang" (*) . Why not USE_GCC ?= any for the poor guys like me who build (some) ports with USE_GCC=4.6 ? For those users with CC installed as gcc (including -stable), this patch should have no effect. Variations of combinations have been heavily tested on pointyhat-west. If there are any regressions, please contact me. Does this override setting CC explicitly in make.conf? Sorry if it's a dumb question, not sure exactly the hierarchy of USE_GCC vs CC in the make system. Matt ___ 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: Clang as default compiler November 4th
On 09/10/12 14:22, Daniel Eischen wrote:
On Mon, 10 Sep 2012, Brooks Davis wrote:
[Please confine your replies to toolch...@freebsd.org to keep the thread
on the most relevant list.]
For the past several years we've been working towards migrating from
GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD
10.0 with Clang as the default compiler on i386 and amd64 platforms. To
this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64
platforms on November 4th.
What does the mean to you?
* When you build world after the default is changed /usr/bin/cc, cpp,
and
c++ will be links to clang.
* This means the initial phase of buildworld and "old style" kernel
compilation will use clang instead of gcc. This is known to work.
* It also means that ports will build with clang by default. A major
of ports work, but a significant number are broken or blocked by
broken ports. For more information see:
http://wiki.freebsd.org/PortsAndClang
What issues remain?
* The gcc->clang transition currently requires setting CC, CXX, and CPP
in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@
to address this shortly.
I assume this will be done, tested and committed before 2012-11-04
(or whenever the switchover date is).
* Ports compiler selection infrastructure is still under development.
This should be a prerequisite before making the switch, given
that ports will be broken without a work-around for building
them with gcc.
I've been using a somewhat dirty method of doing this by checking the
presence of a file in the port's main directory, e.g. if "basegcc" is
present, build with that, if "clang" is present use it, otherwise
default to gcc47. Obviously that configuration is system specific, but
the fundamental idea is look for a file in the ports directory that
dictates the compiler. Perhaps even add a make ccconfig. It works quite
nicely because you can resume a portmaster spree without having to
suspend and change CC manually, or build all clang ports first etc.
Further csup doesn't touch files it doesn't no about, so updating the
tree (without wiping it out) preserves the fact you'd prefer or need to
build a given port with something else.
There are definitely some ports that have been ignoring libmap.conf,
which tends to require me to build some of their dependencies with base
gcc, but otherwise I've been running this system for a few months and it
works quite well...portmaster can upgrade without user intervention, and
it's quite easy to add cflags logic.
Granted this works for me and is probably not the ideal solution...also
hacked on it to post, so probably typos :)
Something like this in make.conf (with fstack-protector-all for all
ports which works great)
.if !empty(.CURDIR:M/usr/ports/*)
CFLAGS+= -fstack-protector-all
.endif
.if empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc47) &&
!exists(basegcc) && !exists(clang)
# this was occasionally necessary
#LDFLAGS+=-lintl
# custom cflags if desired
#CFLAGS+=-custom cflags for gcc47
#custom cputype if desired
CPUTYPE=amdfam10
CC=gcc47
CPP=cpp47
CXX=g++47
.endif
.if empty(.CURDIR:M/usr/ports/*) && exists(/usr/bin/clang) && exists(clang)
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
NO_WERROR=
WERROR=
.endif
Usage is as simple as "touch basegcc" in the port dir or "touch clang"
etc. to select appropriate compiler
Matt
___
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: pkgng questions
On 08/30/12 13:01, Mark Felder wrote: > I think you're very confused about what pkgng is for. At this time, ports > are STILL the recommended way to install things and keep them up to date. Really? I think the last time I compiled X or a web browser (until using poudriere) was about 10 years ago. > Pkgng is the first step required for us to get a better package management > system so we can shift the community towards primarily using packages. I like packages - they save me compiling massive things on my desktop and they let me keep my servers running exactly the same software built from our CI setup. 'make package' is so quick and easy, it'd be hard to beat. So I thought I'd get a grip on pkgng before pkg_* disappears from base. I had a couple of questions I wanted to answer - 1) How easy does it make keeping my desktop (currently releng/9.1 built with dtrace) up-to-date 2) How much easier will it be to maintain production and testing servers? The answer has made me start downloading an OpenIndiana iso. >> 2. Is there a list of ports like nvidia-driver, nspluginwrapper, >> linux-f10-flashplugin, sampleicc (dependency of libreoffice!) which aren't >> in pkgng? > > Everything can be built into the pkgng format except a few ports that need > workarounds. There's a list on the wiki. > > http://wiki.freebsd.org/pkgng > > Go to the bottom "Known Failures" section. I don't see any of the examples I gave listed, apart from nvidia-driver >> 3. How do I force pkg to install/upgrade a single package, regardless of >> dependencies being out of date? > > You should never try to do this anyway; you'll end up with packages built > against the wrong versions of libraries. You're suggesting that I should upgrade an entire machine which may have proven itself over a period of years to be perfectly stable, just because I need a small utility which really doesn't care about the man page typo which caused gettext-0.1.2_3 to change to gettext-0.1.2_4? >> 4. How do I get poudiere to build against a local src/obj tree, or a zfs >> snapshot of a pre-built jail, instead of 9.0-RELEASE? > > The poudriere man page has all the instructions needed to create jails of > any release version to be used for building packages. No, the man page doesn't mention anything about specifying where to pull the distribution from, only what method of access to use. > You don't do it this way. You build everything on your poudriere server and > push all of your packages to the client. You do this every single time. If > you decide you want a new package on your client, you build it on your > poudriere server and have your client request it. If you're using > poudriere/pkgng, your clients should NEVER be compiling ports or installing > packages outside of what your poudriere server is providing. Poudriere is > giving you a "cleanroom" environment where it can guarantee that all the > packages and their required packages/libraries are sane. > Pkgng doesn't require ZFS -- poudriere does. Your clients should never have > poudriere. I am confused. If pkg_* are removed, how is a person with a single desktop machine (worst case, a netbook) expected to operate if they need a specific port build? Are they to spend a week compiling 1000+ ports themselves in a poudriere VM? Or is the flexibility of FreeBSD ports just not deemed to be useful to the end user (or person unable to provide a dedicated any more? >> 8. Is there a pkgng equivalent of 'ls -lt /var/db/pkg' without firing up >> sqlite? > > Are you looking for the date column (not sure why that's useful as it can > change due to many things)? Doesn't "pkg info -a" suffice? 'ls -lt /var/db/pkg' will show me what packages were installed sorted by day. It is very useful on servers which aren't routinely upgraded to the latest and greatest untested versions >> 9. Why didn't pkg upgrade tell me it replaced my custom-built packages? I'd >> have liked for it to not break stuff when /var/db/ports/*/options differed >> from the options I can see pkgng keeps in its metadata... > > Your poudriere server can use you preferred options when it builds > packages. Check the man page. pkg2ng doesn't tell you that you're about to need another machine $ man pkg2ng No manual entry for pkg2ng > Long story short: poudriere is a tool for you to build your OWN private > package repositories (which is really handy!). It is handy IF you have the resources to maintain a poudriere machine. It is handy IF you really enjoy waiting for x.org and web browsers to compile It is NOT handy if you just want to build one package to be built with different options. In fact it makes a mockery of FreeBSD's ease of use. > Pkgng is just the first step towards a large goal of greatly improving > the enduser experience with FreeBSD. By "improving", you mean "removing flexibility from"? > I don't believe pkgng is default on any release yet, so you > shouldn't be using public pkgng repositories for anythi
pkgng questions
1. How do I get pkg to use packages built against 9.1-RC1? VirtualBox is playing up (no ethernet, unkillable crashes, etc) and I suspect it's the kernel module... 2. Is there a list of ports like nvidia-driver, nspluginwrapper, linux-f10-flashplugin, sampleicc (dependency of libreoffice!) which aren't in pkgng? 2a. How do I install libreoffice when a dependency isn't in pkgng? 3. How do I force pkg to install/upgrade a single package, regardless of dependencies being out of date? 4. How do I get poudiere to build against a local src/obj tree, or a zfs snapshot of a pre-built jail, instead of 9.0-RELEASE? 5. How do I get poudiere to build against the packages a pkgng client will use instead of building everything for itself? It might help to reduce the discrepancy between the 30 secs it takes to rebuild sysutils/conky from ports on my desktop, and the >1hour it takes poudiere on a hefty server to download+build X and all its dependencies 6. Is pkgng really replacing base when poudiere requires ZFS? How will ports work if pkg_* are gone? Seriously, shouldn't ports at least be able to work with pkgng, and the default FreeBSD install be to a ZFS root before people are stuffed with the "wrong" choices (UFS) they made? 7. How do I configure pkg to use packages from a certain historical release? I need my servers to be identical software-wise regardless of when I install them. In other words, I DON'T want the latest versions. 8. Is there a pkgng equivalent of 'ls -lt /var/db/pkg' without firing up sqlite? 9. Why didn't pkg upgrade tell me it replaced my custom-built packages? I'd have liked for it to not break stuff when /var/db/ports/*/options differed from the options I can see pkgng keeps in its metadata... -- The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com ___ 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/conky Configure Options in Makefile
On 08/28/12 21:41, Jamie Paul Griffin wrote: > I have installed conky for use with my wm which is Spectrwm. However, > looking in the conky Makefile one of the configure options has been > disabled, tcp monitoring (--disable-portmon), which is a feature i'd > quite like to have available. Is there a reason the maintainer has > disabled this option, perhaps due to security or incompatibility, etc., > that anyone knows of? It appears to be disabled in the port Makefile because Conky's configure script says it's not supported on FreeBSD. cd /usr/ports/*/conky make clean patch vi Makefile - remove the --disable-portmon vi work/conky*/configure - change xLinux to xFreeBSD at line 14043 make Dunno if it actually works, but it does build, albeit with a warning for me: cc -DHAVE_CONFIG_H -I. -DSYSTEM_CONFIG_FILE=\"/usr/local/etc/conky/conky.conf\" -DPACKAGE_LIBDIR=\"/usr/local/lib/conky\" -I/usr/local/include -I/usr/local/include -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -I/usr/local/include/glib-2.0 -D_REENTRANT -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2-I/usr/local/include/lua51 -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include/freetype2 -I/usr/local/include/glib-2.0 -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include -Wall -W -O2 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -MT conky-llua.o -MD -MP -MF .deps/conky-llua.Tpo -c -o conky-llua.o `test -f 'llua.c' || echo './'`llua.c llua.c:43:1: warning: "MIN" redefined In file included from /usr/local/include/glib-2.0/glibconfig.h:9, from /usr/local/include/glib-2.0/glib/gtypes.h:34, from /usr/local/include/glib-2.0/glib/galloca.h:34, from /usr/local/include/glib-2.0/glib.h:32, from libtcp-portmon.h:38, from tcp-portmon.h:25, from conky.h:112, from llua.c:25: /usr/local/include/glib-2.0/glib/gmacros.h:201:1: warning: this is the location of the previous definition The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com ___ 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 not so free anymore ? Long live FreeBSD...
On Sat, 16 Jun 2012 12:00:47 + (UTC) Jerry wrote: > So, are you implying that ALSA (Advanced Linux Sound Architecture) > is never going to happen on a FreeBSD system? Our OSS sound subsystem works (and allows multiple access) without twenty different sound servers, mixers, shim layers and much faffing about, which is how we like it. So no, it's very unlikely we the users are going to put up with some putz wanting to swap that for something that only works when the planets are in the correct alignment after the use of some mystical incantation and the ritual sacrifice of a gnu just to get Skype (which is now owned by MS and is also now a conduit for yet more advertising) going. Sound is one of the things FreeBSD gets very right and most reasonably portable applications are just fine with our implementation of it. There's a compat port for those who want/need the ALSA API. -- Matt Dawson MTD15-RIPE GW0VNR signature.asc Description: PGP signature
Netatalk 2.2.2 disconnection
Hi there, I was fighting the same issue all day as well; the only solution I had found was to downgrade netatalk back to 2.2.1. A new version of the port, netatalk-2.2.2_1,1 , was pushed out just a little while ago and this appears to fix this issue (or at least for me). The new version disables sendfile() by default and makes it optional because apparently it causes issues with ZFS (which does apply in my case). Anyway, I switched to 2.2.2_1,1, making sure that sendfile support was disabled, and now everything works great once again. Cheers, Matt___ 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: New X.Org
On 04/27/12 10:03, Andriy Gapon wrote:
on 26/04/2012 18:45 Warren Block said the following:
On Thu, 26 Apr 2012, matt wrote:
Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus
Errors at the same address whenever certain applications are launched.
Failing examples: Firefox, gedit, qt4-designer Successful: xfce4-terminal,
ioquake3, compiz
Fixed this issue using the changes indicated in the below patch, which
solved my issue with x bus errors. It looks like glxGetScreen was
choking. This may help users with similar problems in compiz or Kwin.
FYI I manually applied changes in the patch to x11-servers/xorg-server,
not sure if the patch below would apply cleanly.
diff --git a/glx/glxdri.c b/glx/glxdri.c
index 326f539..f6ef784 100644
--- a/glx/glxdri.c
+++ b/glx/glxdri.c
@@ -230,7 +230,7 @@ __glXDRIdrawableDestroy(__GLXdrawable *drawable)
/* If the X window was destroyed, the dri DestroyWindow hook will
* aready have taken care of this, so only call if pDraw isn't NULL. */
-if (drawable->pDraw != NULL) {
+if (drawable->pDraw != NULL&& drawable->pDraw->type == DRAWABLE_WINDOW) {
screen = (__GLXDRIscreen *) glxGetScreen(drawable->pDraw->pScreen);
(*screen->core->destroyDrawable)(private->driDrawable);
Good catch! Please enter a PR for this!
Just double-check that this change doesn't introduce any memory/resource leaks
:-)
Verifying this may be beyond my xorg-fu...what's the best way to examine
this?
Matt
___
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: New X.Org
On 04/24/12 23:38, matt wrote: > On 04/23/12 09:37, Warren Block wrote: >> On Mon, 23 Apr 2012, matt wrote: >> >>> On 04/23/12 05:59, Warren Block wrote: >>>> On Mon, 23 Apr 2012, Andrea Venturoli wrote: >>>> >>>>> I have a Radeon card, so, does this mean I will get xorg-server? Any >>>>> way to get 1.10? Any advantage into this? >>>> >>>> A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa >>>> 7.11. So far there are no Firefox title bar artifacts like there were >>>> occasionally with the earlier version. >>>> >>>>> Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? >>>> >>>> Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, >>>> xorg-server, xf86-input-*, xf86-video-*, and... a few other things I >>>> should have taken notes on. >> >>> Interesting. Another Radeon 4650 (rv730) is not working here, giving >>> Bus >>> Errors at the same address whenever certain applications are launched. >>> Failing examples: Firefox, gedit, qt4-designer >>> Successful: xfce4-terminal, ioquake3, compiz >>> >>> I just completed recompiling all ports dependent on libGL with no luck. >>> I had "WITHOUT_NOUVEAU" in make.conf at the same time as >>> "WITH_NEW_XORG", is that the problem? >>> Does this sound like an Xorg problem or a ports/ld problem? >> >> I also did 'portmaster driconf', which rebuilt libglut and libGLU. >> Run pkg_libchk from sysutils/bsdadminscripts to check for missing >> libraries. >> > I rebuilt most ports, the rest are rebuilding now. > The problem can be excluded by not running my normal xinitrc, however > I do think this may be either an X or base system bug? > Test case for creating this involves starting with my normal xinitrc, > desktop appears, then launching Thunar. Closing a window also causes > the crash. > > Here is a complete backtrace...can anyone make any sense of this? Is > this related to the libthr.so.3 issues recently on CURRENT? > > > Program received signal SIGBUS, Bus error. > 0x000803bc8bb2 in glxGetScreen () >from /usr/local/lib/xorg/modules/extensions/libglx.so > (gdb) > Continuing. > > Program received signal SIGABRT, Aborted. > 0x000803254bbc in thr_kill () from /lib/libc.so.7 > (gdb) bt > #0 0x000803254bbc in thr_kill () from /lib/libc.so.7 > #1 0x0008032fee9b in abort () from /lib/libc.so.7 > #2 0x0046ceff in OsAbort () > #3 0x00479bfc in ddxGiveUp () > #4 0x000a in ?? () > #5 0x7d25c10fe5bd6725 in ?? () > #6 0x00593830 in ?? () > #7 0x004694ee in LogSetParameter () > #8 0x00469743 in FatalError () > #9 0x0046a703 in OsLookupColor () > #10 0x01116c00 in ?? () > #11 0x7d25c10fe5bd6725 in ?? () > #12 0x7fffd3a0 in ?? () > #13 0x0100e400 in ?? () > #14 0x7fffd780 in ?? () > #15 0x000802fdf1be in pthread_sigmask () from /lib/libthr.so.3 > #16 0x000802fdf34b in pthread_sigmask () from /lib/libthr.so.3 > #17 0x7043 in ?? () > #18 0x000802fdf270 in pthread_sigmask () from /lib/libthr.so.3 > #19 0x in ?? () > #20 0x in ?? () > #21 0x in ?? () > #22 0x in ?? () > ---Type to continue, or q to quit--- > #23 0x5a5a5a5a5a5a5a5a in ?? () > #24 0x03380100 in ?? () > #25 0x0008035454a0 in __des_crypt_LOCAL () from /lib/libc.so.7 > #26 0x0001 in ?? () > #27 0x in ?? () > #28 0x000a8008 in ?? () > #29 0x0118 in ?? () > #30 0x0001 in ?? () > #31 0x0080ccf8 in screenInfo () > #32 0x04c00dc0 in ?? () > #33 0x04c97000 in ?? () > #34 0x03380100 in ?? () > #35 0x0080ccc0 in ScreenSaverBlanking () > #36 0x0008035454a0 in __des_crypt_LOCAL () from /lib/libc.so.7 > #37 0x008026c0 in RegionEmptyBox () > #38 0x001b00130009 in ?? () > #39 0x in ?? () > #40 0x003b003b0001 in ?? () > #41 0x in ?? () > #42 0x000803bc8bb2 in glxGetScreen () >from /usr/local/lib/xorg/modules/extensions/libglx.so > #43 0x0043 in ?? () > #44 0x00013202 in ?? () > ---Type to continue, or q to quit--- > #45 0x7fffd850 in ?? () > #46 0x003b in ?? () > #47 0x0320 in ?? () > #48 0x00010002 in ?? () > #49 0x00020002 in ?? () > #50 0x037f in ?? () > #51
Re: New X.Org
On 04/23/12 09:37, Warren Block wrote: On Mon, 23 Apr 2012, matt wrote: On 04/23/12 05:59, Warren Block wrote: On Mon, 23 Apr 2012, Andrea Venturoli wrote: I have a Radeon card, so, does this mean I will get xorg-server? Any way to get 1.10? Any advantage into this? A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa 7.11. So far there are no Firefox title bar artifacts like there were occasionally with the earlier version. Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, xorg-server, xf86-input-*, xf86-video-*, and... a few other things I should have taken notes on. Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus Errors at the same address whenever certain applications are launched. Failing examples: Firefox, gedit, qt4-designer Successful: xfce4-terminal, ioquake3, compiz I just completed recompiling all ports dependent on libGL with no luck. I had "WITHOUT_NOUVEAU" in make.conf at the same time as "WITH_NEW_XORG", is that the problem? Does this sound like an Xorg problem or a ports/ld problem? I also did 'portmaster driconf', which rebuilt libglut and libGLU. Run pkg_libchk from sysutils/bsdadminscripts to check for missing libraries. I rebuilt most ports, the rest are rebuilding now. The problem can be excluded by not running my normal xinitrc, however I do think this may be either an X or base system bug? Test case for creating this involves starting with my normal xinitrc, desktop appears, then launching Thunar. Closing a window also causes the crash. Here is a complete backtrace...can anyone make any sense of this? Is this related to the libthr.so.3 issues recently on CURRENT? Program received signal SIGBUS, Bus error. 0x000803bc8bb2 in glxGetScreen () from /usr/local/lib/xorg/modules/extensions/libglx.so (gdb) Continuing. Program received signal SIGABRT, Aborted. 0x000803254bbc in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x000803254bbc in thr_kill () from /lib/libc.so.7 #1 0x0008032fee9b in abort () from /lib/libc.so.7 #2 0x0046ceff in OsAbort () #3 0x00479bfc in ddxGiveUp () #4 0x000a in ?? () #5 0x7d25c10fe5bd6725 in ?? () #6 0x00593830 in ?? () #7 0x004694ee in LogSetParameter () #8 0x00469743 in FatalError () #9 0x0046a703 in OsLookupColor () #10 0x01116c00 in ?? () #11 0x7d25c10fe5bd6725 in ?? () #12 0x7fffd3a0 in ?? () #13 0x0100e400 in ?? () #14 0x7fffd780 in ?? () #15 0x000802fdf1be in pthread_sigmask () from /lib/libthr.so.3 #16 0x000802fdf34b in pthread_sigmask () from /lib/libthr.so.3 #17 0x7043 in ?? () #18 0x000802fdf270 in pthread_sigmask () from /lib/libthr.so.3 #19 0x in ?? () #20 0x in ?? () #21 0x in ?? () #22 0x in ?? () ---Type to continue, or q to quit--- #23 0x5a5a5a5a5a5a5a5a in ?? () #24 0x03380100 in ?? () #25 0x0008035454a0 in __des_crypt_LOCAL () from /lib/libc.so.7 #26 0x0001 in ?? () #27 0x in ?? () #28 0x000a8008 in ?? () #29 0x0118 in ?? () #30 0x0001 in ?? () #31 0x0080ccf8 in screenInfo () #32 0x04c00dc0 in ?? () #33 0x04c97000 in ?? () #34 0x03380100 in ?? () #35 0x0080ccc0 in ScreenSaverBlanking () #36 0x0008035454a0 in __des_crypt_LOCAL () from /lib/libc.so.7 #37 0x008026c0 in RegionEmptyBox () #38 0x001b00130009 in ?? () #39 0x in ?? () #40 0x003b003b0001 in ?? () #41 0x in ?? () #42 0x000803bc8bb2 in glxGetScreen () from /usr/local/lib/xorg/modules/extensions/libglx.so #43 0x0043 in ?? () #44 0x00013202 in ?? () ---Type to continue, or q to quit--- #45 0x7fffd850 in ?? () #46 0x003b in ?? () #47 0x0320 in ?? () #48 0x00010002 in ?? () #49 0x00020002 in ?? () #50 0x037f in ?? () #51 0x in ?? () #52 0x in ?? () #53 0x00021fa0 in ?? () #54 0x68741582 in ?? () #55 0x in ?? () #56 0x in ?? () #57 0x in ?? () #58 0x in ?? () #59 0x in ?? () #60 0x in ?? () #61 0x in ?? () #62 0x in ?? () #63 0x in ?? () #64 0x191b in ?? () #65 0x in ?? () #66 0x in ?? () #67 0x in ?? () ---Type to continue, or q to quit--- #68 0x in ?? () #69 0x in ?? () #70 0x47012f00 in ?? () #71 0x in ?? () #72 0x4b7f in ?? () #73 0x in ?? () #74 0x44d3 in ?? () #75 0x in ?? () #76 0
Re: New X.Org
On 04/23/12 09:37, Warren Block wrote: > On Mon, 23 Apr 2012, matt wrote: > >> On 04/23/12 05:59, Warren Block wrote: >>> On Mon, 23 Apr 2012, Andrea Venturoli wrote: >>> >>>> I have a Radeon card, so, does this mean I will get xorg-server? Any >>>> way to get 1.10? Any advantage into this? >>> >>> A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa >>> 7.11. So far there are no Firefox title bar artifacts like there were >>> occasionally with the earlier version. >>> >>>> Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? >>> >>> Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, >>> xorg-server, xf86-input-*, xf86-video-*, and... a few other things I >>> should have taken notes on. > >> Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus >> Errors at the same address whenever certain applications are launched. >> Failing examples: Firefox, gedit, qt4-designer >> Successful: xfce4-terminal, ioquake3, compiz >> >> I just completed recompiling all ports dependent on libGL with no luck. >> I had "WITHOUT_NOUVEAU" in make.conf at the same time as >> "WITH_NEW_XORG", is that the problem? >> Does this sound like an Xorg problem or a ports/ld problem? > > I also did 'portmaster driconf', which rebuilt libglut and libGLU. > Run pkg_libchk from sysutils/bsdadminscripts to check for missing > libraries. Unfortunately no good missing libs: # pkg_libchk opera-11.62_1: /usr/local/lib/opera/liboperakde4.so misses libkdecore.so.7 opera-11.62_1: /usr/local/lib/opera/liboperakde4.so misses libkdeui.so.7 opera-11.62_1: /usr/local/lib/opera/liboperakde4.so misses libkio.so.7 I removed all of /usr/local/lib32 beforehand, just in case... I will rebuild glut & GLU and anything else. Is there anyway to get a backtrace on X? Is it as easy as gdb startx? Matt ___ 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: New X.Org
On 04/23/12 09:37, Warren Block wrote: > On Mon, 23 Apr 2012, matt wrote: > >> On 04/23/12 05:59, Warren Block wrote: >>> On Mon, 23 Apr 2012, Andrea Venturoli wrote: >>> >>>> I have a Radeon card, so, does this mean I will get xorg-server? Any >>>> way to get 1.10? Any advantage into this? >>> >>> A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa >>> 7.11. So far there are no Firefox title bar artifacts like there were >>> occasionally with the earlier version. >>> >>>> Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? >>> >>> Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, >>> xorg-server, xf86-input-*, xf86-video-*, and... a few other things I >>> should have taken notes on. > >> Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus >> Errors at the same address whenever certain applications are launched. >> Failing examples: Firefox, gedit, qt4-designer >> Successful: xfce4-terminal, ioquake3, compiz >> >> I just completed recompiling all ports dependent on libGL with no luck. >> I had "WITHOUT_NOUVEAU" in make.conf at the same time as >> "WITH_NEW_XORG", is that the problem? >> Does this sound like an Xorg problem or a ports/ld problem? > > I also did 'portmaster driconf', which rebuilt libglut and libGLU. > Run pkg_libchk from sysutils/bsdadminscripts to check for missing > libraries. Definitely rebuilt libglut and driconf, I'm pretty sure I saw libGLU. Haven't run pkg_libchk yet, great idea. I did run pkgdb -F and rebuild a few hundred ports hoping to shotgun fix it. I was experimenting with wine 3d acceleration a week or so ago, it's possible something broken happened as a result of mounting ports dir inside the chroot...or /usr/local/lib32 stuff? I also have AIGLX on in Xorg.conf from that adventure. Problem arose on first startx after the update, however, so it's not clear. Matt ___ 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: New X.Org
On 04/23/12 07:40, Zhihao Yuan wrote: > On Mon, Apr 23, 2012 at 9:28 AM, matt wrote: >> On 04/23/12 05:59, Warren Block wrote: >>> On Mon, 23 Apr 2012, Andrea Venturoli wrote: >>> >>>> I have a Radeon card, so, does this mean I will get xorg-server? Any >>>> way to get 1.10? Any advantage into this? >>> A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa >>> 7.11. So far there are no Firefox title bar artifacts like there were >>> occasionally with the earlier version. >>> >>>> Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? >>> Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, >>> xorg-server, xf86-input-*, xf86-video-*, and... a few other things I >>> should have taken notes on. >>> ___ >>> freebsd-...@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-x11 >>> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" >> Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus >> Errors at the same address whenever certain applications are launched. >> Failing examples: Firefox, gedit, qt4-designer >> Successful: xfce4-terminal, ioquake3, compiz >> >> I just completed recompiling all ports dependent on libGL with no luck. >> I had "WITHOUT_NOUVEAU" in make.conf at the same time as >> "WITH_NEW_XORG", is that the problem? > WITHOUT_NOUVEAU has no effect; only WITH_NEW_XORG has. > Any crash log? Xorg.0.log? > >> Does this sound like an Xorg problem or a ports/ld problem? >> >> Matt >> ___ >> 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" > > Partially truncated, but here's the last couple kilobytes of Xorg.0.log. http://pastebin.com/7JHyXYH1 Short version is " [ 36202.557] Bus error: 10 at address 0x803bc24e2 " The address never changes, whenever Xorg crashes since the update. System compiled with base cc (gcc), ports are a mix of gcc & gcc47...I did my recompile with gcc only in case it was a gcc47/libmap.conf issue. Matt ___ 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: New X.Org
On 04/23/12 05:59, Warren Block wrote: > On Mon, 23 Apr 2012, Andrea Venturoli wrote: > >> I have a Radeon card, so, does this mean I will get xorg-server? Any >> way to get 1.10? Any advantage into this? > > A Radeon 4650 is working fine here with xorg-server 1.10.6 and mesa > 7.11. So far there are no Firefox title bar artifacts like there were > occasionally with the earlier version. > >> Also, I have WITHOUT_NOUVEAU in /etc/make.conf. Should I remove it? > > Yes, replace it with WITH_NEW_XORG=yes. Then rebuild graphics/libdrm, > xorg-server, xf86-input-*, xf86-video-*, and... a few other things I > should have taken notes on. > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" Interesting. Another Radeon 4650 (rv730) is not working here, giving Bus Errors at the same address whenever certain applications are launched. Failing examples: Firefox, gedit, qt4-designer Successful: xfce4-terminal, ioquake3, compiz I just completed recompiling all ports dependent on libGL with no luck. I had "WITHOUT_NOUVEAU" in make.conf at the same time as "WITH_NEW_XORG", is that the problem? Does this sound like an Xorg problem or a ports/ld problem? Matt ___ 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: Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. (
On Monday 21 Nov 2011 16:09:45 Conrad J. Sabatier wrote: > On Mon, 21 Nov 2011 07:42:43 -0600 > > eculp wrote: > > I have tried building both from the different ports and even more > > using portmaster and all stop ate similar locations in kdelabs4. > > Maybe there is something that I should or could build first. > > > > Thanks, > > > > ed > > > > errors follow: > > > > kdelibs stops here: > > > > Generating kurlnavigator.moc > > Generating moc_kdiroperatordetailview_p.cpp > > [ 1%] Built target kfile_automoc > > Scanning dependencies of target kdeinit_kconf_update_automoc > > Scanning dependencies of target docbookl10nhelper_automoc > > [ 1%] Built target kdeinit_kconf_update_automoc > > [ 1%] Built target docbookl10nhelper_automoc > > Scanning dependencies of target genshortcutents_automoc > > Scanning dependencies of target kio_ghelp_automoc > > [ 1%] Built target genshortcutents_automoc > > [ 1%] Built target kio_ghelp_automoc > > Scanning dependencies of target kio_help_automoc > > Scanning dependencies of target meinproc4_automoc > > [ 1%] Built target kio_help_automoc > > [ 1%] Built target meinproc4_automoc > > Scanning dependencies of target meinproc4_simple_automoc > > Scanning dependencies of target kio_file_automoc > > [ 1%] Built target meinproc4_simple_automoc > > > > kdepimlibs4 stops here: > > > > Scanning dependencies of target kimg_pcx_automoc > > Scanning dependencies of target kimg_pic_automoc > > [ 1%] Built target kimg_pcx_automoc > > [ 1%] Built target kimg_pic_automoc > > Scanning dependencies of target kimg_psd_automoc > > Scanning dependencies of target kimg_ras_automoc > > [ 1%] Built target kimg_psd_automoc > > [ 1%] Built target kimg_ras_automoc > > Scanning dependencies of target kimg_rgb_automoc > > Scanning dependencies of target kimg_tga_automoc > > [ 1%] Built target kimg_rgb_automoc > > [ 1%] Built target kimg_tga_automoc > > Scanning dependencies of target kimg_xcf_automoc > > Scanning dependencies of target kimg_xview_automoc > > [ 1%] Built target kimg_xview_automoc > > [ 1%] Built target kimg_xcf_automoc > > Scanning dependencies of target kdnssd_automoc > > Scanning dependencies of target krosscore_automoc > > Generating interpreter.moc > > Generating script.moc > > Generating action.moc > > Generating actioncollection.moc > > Generating manager.moc > > [ 1%] Built target krosscore_automoc > > So where are the errors? There are none in the output you posted. Tinderbox logs of the same problem: https://chronos.org.uk/tb/errors/8-amd64-Desktop/kdelibs-4.7.3.log By selectively changing MAKE_JOBS_SAFE to MAKE_JOBS_UNSAFE in the Makefiles I can compile most of KDE-SC barring kdeplasma-addons. This is from a pristine ports tree updated yesterday with no modifications. Fails consistently on kdelibs4, but in different places each time. @eculp: Is your machine SMP? This tinderbox is a quad core MP box. -- Matt Dawson MTD15-RIPE m...@chronos.org.uk ___ 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: Update on ports on 10.0
On Oct 11, 2011 5:07 PM, "Erwin Lansing" wrote: > > Since the release has been pushed back some more since the last mail, we > do have some time to test a possible fix for the issues we're seeing > with libtool on FreeBSD 10.0. [snip] > to move forward. Other options include the big find/grep/awk solution > that has been posted several times and fiddling with uname to go to > FreeBSD 9.99 for a while, while ports can be fixed. I would vote for a prominent message in the places people who run -CURRENT are meant to pay attention to (this mailing list and UPDATING and the ports equivalents). The message should point people to a web site (wiki?) with the latest news on how to report and provide patches for fixes with guidance on typical solutions. After all, this is -CURRENT and it's users are meant to be contributing fixes and are not expected to require their hands to be held. This I believe would be a good method to leverage the community so as to distribute the fixup problem. In particular the hack of 9.99 is likely to cause more problems and should be avoided. My 2¢ ___ 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: HEADS UP: ports/ and 10.0-CURRENT
On 09/28/11 15:41, Hartmann, O. wrote: On 09/28/11 22:18, Doug Barton wrote: On 09/28/2011 12:39, Hartmann, O. wrote: The mess started to happen when I tried to "repair" a non CLANG compiling port math/gotoblas with portmaster -vf amth/gotoblas. Since this build binutils and even gettext and libiconv, I guess they got broken. Last I saw was a successful installation report from portmaster. But the libiconv.so.3 wasn't there anymore when I checked! This is a catastrophy ... I'm on FreeBSD 10.0-CURRENT r225844 It's been widely reported on the ports list that you can't do fresh ports compiles on 10-current, and won't be able to until well after 9.0-RELEASE. The primary reason is that auto* stuff doesn't understand the 2-digit release version. Solutions are to set UNAME_r=9.0-CURRENT in your environment, and/or twiddle the version in newvers.sh and rebuild/reinstall your kernel. hth, Doug Yes, it has been discussed. But I was too dumb to realise that the phenomenon I experienced was triggered by this. I'll stay tuned and watch when a solution is at hand. Regards, Oliver I also was apparently too dumb! Making progress with UNAME_r and newvers.sh as we speak. I was unable to compile neon29 properly with UNAME_r alone... buildkernel underway. At least it's never boring! Thanks all Matt ___ 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/cfs
On 09/08/11 17:54, Matthias Andree wrote: > The port isn't perfectly usable (because that would mean it's usable in > all circumstances for all advertised purposes, which is explicitly not > the case in the light of known vulnerabilities). In British Engligh at least, "perfectly" can mean "adequately" e.g. A scaffold pole and a short wall is a perfectly usable jack for changing a car tyre. Apologies. However, it is still the case that software with known security vulnerabilities is almost always still usable for the most part. If the kernel had a flaw which took someone with a username exactly 17 characters long to have UID 0, would you refuse to, or be unable to use the operating system until it's fixed? What if I mentioned FreeBSD has a 16-character hard-coded limit on usernames? > Nobody stands there pointing a gun at your head and forces you to > uninstall a port that got removed from the ports/ tree. If someone deletes a package I use from ports, they are FORCING me to jump through an awful load of hoops to get what I want/need. Let's look at the subject of this thread: What happens if I'm a CFS user and my hard disk dies? I install the latest release, pull my backups back in, and find that the FreeBSD people have decided they don't want me to be able to access my encrypted data any more. What do I do? Attempt to compile CFS from vendor source? Waste time trying to re-make a port? Install the ports tree from a FreeBSD6.1 CD I have lying around? Just install some other OS? What exactly is the administrative overhead of having a FORBIDDEN, etc port in the tree if it compiles, works, and people are happy to use it regardless of its flaws? ___ 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/cfs
On 09/07/11 17:04, Chris Rees wrote: >> The /new/ policy of removing ports for much lighter offenses, such as > having vulnerabilities, has already caused so many objections, that it is > time to abolish it. > > I consider the argument here dead; portmgr is reviewing the policy as Erwin > has said. > > However... I find it deeply troubling that you consider buildability more > important than security fixes. Are you actually serious? Changing to a hypothetical example, why would an Apache vulnerability in mod_rewrite in the least bit bother a person who doesn't have the module enabled, which I believe is the standard configuration? Would you prefer Apache be deleted from ports if it took longer than expected to fix it? I've still got non-networked FreeBSD 4.x laptops running with a version of Minicom that for a year or so was FORBIDDEN because it had a local root vulnerability. What's so wrong about that? I'm glad the port wasn't deleted because I still install and use Minicom today. What the current FreeBSD policy of actively deleting perfectly usable ports instead of putting a mild hurdle in the way is saying, is that FreeBSD will stop me doing what I may want to do because FreeBSD knows best. I want machines, tools, to do as *I* say not the other way round, whether it's good for me or not. If I wanted nannying and interference, I'd install Ubuntu. ___ 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: test
sorry ignore this wrong email address On Fri, Jun 17, 2011 at 8:33 PM, matt donovan wrote: > test > > -- > Technological progress is like an ax in the hands of a pathological > criminal. > -*Albert Einstein > > Breadth of Unix experience and depth of knowledge in the world of servers. > > * > > -- Technological progress is like an ax in the hands of a pathological criminal. -*Albert Einstein Breadth of Unix experience and depth of knowledge in the world of servers. * ___ 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: postfix-2.6.5 on freebsd 8.0-release
On Mon, Jan 18, 2010 at 2:17 PM, Lucas Reddinger wrote: > Hello, > > Upon the installation (``pkg_add -r'') of postfix, I was asked, as > usual, to disable some daily routines. > > > And you can disable some sendmail specific daily maintenance routines in > your > > /etc/periodic.conf file: > > > > daily_clean_hoststat_enable="NO" > > daily_status_mail_rejects_enable="NO" > > daily_status_include_submit_mailq="NO" > > daily_submit_queuerun="NO" > > However, on Freebsd 8.0 release, ``/etc/periodic.conf'' does not > exist. I believe that the contents of ``/etc/periodic/daily'' are > relevant here. > > What is the preferred method of performing these actions now? Create the file /etc/periodic.conf and add those assignments to it. Matt > ___ 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: security/openssl BROKEN, DEPRECATED, and EXPIRED?
On Wednesday 13 Jan 2010 13:34:29 I wrote: > I suspect that there's an update on its way, although that doesn't help > the rest of us using ports in the meantime. For now, I'd personally > recommend to use a date=2010.01.12.15.42.00 definition in your ports > supfile until all of this shakes out. And, just like magic, it's fixed with a commit at 13:30 UTC. Disregard the above. -- Matt Dawson MTD15-RIPE m...@chronos.org.uk signature.asc Description: This is a digitally signed message part.
Re: security/openssl BROKEN, DEPRECATED, and EXPIRED?
On Wednesday 13 Jan 2010 12:00:23 Trix Farrar wrote: > What happened? I haven't been able to find any discussion about this > on either freebsd-ports, freebsd-ports-bugs, or freebsd-security. > There doesn't seem to be a PR, either. > > Am I just being overly sensitive or does this present a POLA problem? > My ports tree is up to date, but OpenSSL can't be upgraded, and > neither can anything that depends on it. If you have a look at the last commit for Mk/bsd.openssl.mk, you'll see the libcrypto versions have been bumped, too. 8.0-RELEASE has 0.9.8k in base, but this .mk looks for libcrypto.so.7 and the version conditional has been dropped (not that it would have made any difference set to 800105) so dropping back to the version in the base system is going to be no help either. Even HEAD is still on 0.9.8k (libcrypto.so.6). http://bit.ly/7h5PpU (CVSweb) I suspect that there's an update on its way, although that doesn't help the rest of us using ports in the meantime. For now, I'd personally recommend to use a date=2010.01.12.15.42.00 definition in your ports supfile until all of this shakes out. As for POLA, I can think of nothing more astonishing than finding that my systems cannot, under any circumstances, meet the requirements of bsd.openssl.mk, thus breaking nearly everything important. That sort of snuck up on me without warning... -- Matt Dawson MTD15-RIPE m...@chronos.org.uk signature.asc Description: This is a digitally signed message part.
Re: FreeBSD Port: php5-mhash-5.2.11_1
On Wed, Dec 16, 2009 at 7:53 PM, Raphael Becker wrote:
>
> I disabled those:
> #extension=openssl.so
> #extension=pdo_mysql.so
> #extension=ldap.so
> #extension=imap.so
> #extension=mhash.so
> #extension=ftp.so
> #extension=curl.so
> #extension=mysqli.so
>
>
> If i enable any of those php will segfault again!
>
> Looking at the referenced libraries from the ports (usr/local) shows a
> hot candidate:
>
> [r...@freebsd ~]# for SO in $(grep ^[#] /usr/local/etc/php/extensions.ini |
> cut -f 2 -d "="); do ldd /usr/local/lib/php/20060613/$SO; done |
> grep usr/local | awk '{ print $1 " => " $3 ; }' | sort | uniq -c | sort -n
>
> [snip]
> 2 libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15
> 7 libcrypto.so.5 => /usr/local/lib/libcrypto.so.5
> 7 libssl.so.5 => /usr/local/lib/libssl.so.5
>
> 7 out of 8 disabled extensions depend on libcrypto.so.5 and libssl.so.5
> which come from openssl-0.9.8l
>
You might want to check out this thread:
http://lists.freebsd.org/pipermail/freebsd-ports/2009-December/058256.html
Perhaps your issues are related.
Matt
___
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: The new cups ports seem to not recognize usb printers on FreeBSD 7.2-STABLE
On Sunday 06 Dec 2009 12:00:23 freebsd-ports-requ...@freebsd.org wrote:
> On Sunday 06 Dec 2009 00:00:03 freebsd-ports-requ...@freebsd.org wrote:
> > > An option WITH_LIBUSB was added to the cups-base/Makefile. That's
> > > probably what Dirk meant.
> >
> >
> > Thanks for the explanation, Gary. I have it set with make config
> > but just hardcoded it into the Makefile and am recompiling but I
> > doubt it will change but there is still hope. ;)
>
> The attached patch works on 8.0-RELEASE for me, restoring the
> non-libusb functionality. Leave the libusb option disabled and just
> compile as normal.
The attached couple of patches fix this port in all cases, tested with
tinderbox. Since libusb is in base for FBSD>8 it needs handling
differently. Note well that if you use libusb, you need to NOT attach the
ulpt* driver to the device, i.e. remove ulpt from your kernel or don't load
it at boot.
Also fixed is the CUPS_OVERWRITE_BASE case deinstall, restoring the correct
permissions to lp and friends.
--
Matt Dawson
MTD15-RIPE
m...@chronos.org.uk
--- ./ports/print/cups-base/Makefile.orig 2009-12-06 11:02:46.0 +
+++ ./ports/print/cups-base/Makefile 2009-12-06 12:21:21.0 +
@@ -173,8 +173,13 @@
RUN_DEPENDS+= xdg-open:${PORTSDIR}/devel/xdg-utils
.endif
-.if !defined(CUPS_CLIENT) && !defined(CUPS_IMAGE) && defined(WITH_LIBUSB)
+.if !defined(CUPS_CLIENT) && !defined(CUPS_IMAGE) && defined(WITH_LIBUSB) && ${OSVERSION}>80
+CPPFLAGS+= -I/usr/include
+LDFLAGS+= -L/usr/lib
+.elif !defined(CUPS_CLIENT) && !defined(CUPS_IMAGE) && defined(WITH_LIBUSB) && ${OSVERSION}<79
LIB_DEPENDS+= usb:${PORTSDIR}/devel/libusb
+.else
+CONFIGURE_ARGS+= --disable-libusb
.endif
.if defined(CUPS_CLIENT)
--- ./ports/print/cups-base/pkg-plist.orig 2009-12-06 12:23:00.0 +
+++ ./ports/print/cups-base/pkg-plist 2009-12-06 12:24:18.0 +
@@ -20,6 +20,11 @@
%%overwrit...@exec if test -e /usr/bin/lpr; then chmod -h 0 /usr/bin/lpr; fi
%%overwrit...@exec if test -e /usr/bin/lprm; then chmod -h 0 /usr/bin/lprm; fi
%%overwrit...@exec if test -e /usr/sbin/lpc; then chmod -h 0 /usr/sbin/lpc; fi
+%%overwrit...@unexec if test -e /usr/bin/lp; then chmod -h 0555 /usr/bin/lp; fi
+%%overwrit...@unexec if test -e /usr/bin/lpq; then chmod -h 06555 /usr/bin/lpq; fi
+%%overwrit...@unexec if test -e /usr/bin/lpr; then chmod -h 06555 /usr/bin/lpr; fi
+%%overwrit...@unexec if test -e /usr/bin/lprm; then chmod -h 06555 /usr/bin/lprm; fi
+%%overwrit...@unexec if test -e /usr/sbin/lpc; then chmod -h 02555 /usr/sbin/lpc; fi
@unexec if cmp -s %D/etc/cups/cupsd.conf.N %D/etc/cups/cupsd.conf; then rm -f %D/etc/cups/cupsd.conf; fi
etc/cups/cupsd.conf.N
@exec if test ! -f %D/etc/cups/cupsd.conf; then cp -p %D/etc/cups/cupsd.conf.N %D/etc/cups/cupsd.conf; fi
signature.asc
Description: This is a digitally signed message part.
Re: The new cups ports seem to not recognize usb printers on FreeBSD 7.2-STABLE
On Sunday 06 Dec 2009 11:17:52 you wrote: > On Sunday 06 Dec 2009 00:00:03 freebsd-ports-requ...@freebsd.org wrote: > > > An option WITH_LIBUSB was added to the cups-base/Makefile. That's > > > probably what Dirk meant. > > > > Thanks for the explanation, Gary. I have it set with make config but > > just hardcoded it into the Makefile and am recompiling but I doubt it > > will change but there is still hope. ;) > > The attached patch works on 8.0-RELEASE for me, restoring the non-libusb > functionality. Leave the libusb option disabled and just compile as > normal. > Gah, sorry about the subject line. Won't happen again. -- Matt Dawson MTD15-RIPE m...@chronos.org.uk signature.asc Description: This is a digitally signed message part.
Re: freebsd-ports Digest, Vol 341, Issue 7
On Sunday 06 Dec 2009 00:00:03 freebsd-ports-requ...@freebsd.org wrote:
> > An option WITH_LIBUSB was added to the cups-base/Makefile. That's
> > probably what Dirk meant.
>
> Thanks for the explanation, Gary. I have it set with make config but
> just hardcoded it into the Makefile and am recompiling but I doubt it
> will change but there is still hope. ;)
The attached patch works on 8.0-RELEASE for me, restoring the non-libusb
functionality. Leave the libusb option disabled and just compile as normal.
--
Matt Dawson
MTD15-RIPE
m...@chronos.org.uk
--- ./ports/print/cups-base/Makefile.orig 2009-12-06 11:02:46.0 +
+++ ./ports/print/cups-base/Makefile 2009-12-06 11:09:36.0 +
@@ -175,6 +175,8 @@
.if !defined(CUPS_CLIENT) && !defined(CUPS_IMAGE) && defined(WITH_LIBUSB)
LIB_DEPENDS+= usb:${PORTSDIR}/devel/libusb
+.else
+CONFIGURE_ARGS+= --disable-libusb
.endif
.if defined(CUPS_CLIENT)
___
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: [HEADUP] FreeBSD Gecko's TODO and plan for future
On Sat, Aug 22, 2009 at 5:35 PM, Jeremy Messenger wrote: > On Sat, 22 Aug 2009 15:52:43 -0500, wrote: > > Martin Wilke wrote: >> >>> Background: >>> We have a lot of old stuff on the portstree and it's time >>> to cleanup old stuff. >>> >> ... >> >>> * www/nvu last official release was in 2005, no longer >>> supported, and also some vulnerabilities. We have >>> www/kompozer which also need an update to get this >>> unbroken. >>> >> ... >> >>> Problems which we have to solve: >>> Some Gnome ports need www/firefox to build and work, >>> but unfortunately firefox2 isn't longer supported by >>> the Mozilla Foundation. >>> >> >> So, if I am understanding this correctly, it's proposed to >> replace nvu with an updated kompozer, which to judge from >> the name is part of KDE. Thus Gnome acquires a dependency >> on KDE by way of firefox/gecko? This does not seem like a >> Good Thing (TM). >> > > Why don't you check what kompozer is first? ;-) > > Cheers, > Mezz > > > -- > me...@cox.net - m...@freebsd.org > FreeBSD GNOME Team > http://www.FreeBSD.org/gnome/ - gn...@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" > kompozer is NVU KompoZer is an unoffical bugfix/update aka a fork ___ 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: [HEADUP] FreeBSD Gecko's TODO and plan for future
On Sat, Aug 22, 2009 at 3:12 PM, J.-P. Klodzinski wrote: > matt donovan wrote: > > On Sat, Aug 22, 2009 at 2:22 PM, Martin Wilke wrote: > > > > Howdy Guys, > > > > The FreeBSD Gecko Team will let you know what the plans for > > the future are and on what we are currently working. > > > > Goals: > > * Removal of mozilla, nvu, xulrunner and firefox2. > > * www/firefox35 should be moved to www/firefox. > > * The options USE_GECKO mozilla nvu xulrunner and firefox will be also > > removed. > > > > Background: > > We have a lot of old stuff on the portstree and it's time to cleanup old > > stuff. > > * www/mozilla is 5 year old now, no longer supported by upstream, and > > has many many vulnerabilities. We can use www/seamonkey. > > > > * www/nvu last official release was in 2005, no longer supported, and > > also some vulnerabilities. We have www/kompozer which also need an > > update to get this unbroken. > > > > * www/xulrunner is old and was replaced by www/libxul. We should not > > hold any old Gecko stuff. Also it's not longer supported by > > upstream: > > https://wiki.mozilla.org/XULRunner:Roadmap > > > > Problems which we have to solve: > > Some Gnome ports need www/firefox to build and work, but unfortunately > > firefox2 isn't longer supported by the Mozilla Foundation. Also > > www/firefox has a lot of vulnerabilities. We should www/firefox > > mark FORBIDDEN at this time gives no fixes for the latest securtiy > > reports. > > > > We see here 2 ways: > > 1) The Gnome Team (not the FreeBSD Gnome Team) take time and move > all > > his > > stuff to libxul. > > 2) or we the FreeBSD Team have to remove all these ports. We know > > that's > > really hard but we should not hold vulnerabilities stuff. > > > > We hope to get here a bit help from the FreeBSD Gnome Team to make it > > possible to get some stuff to work with the current libxul version. > > > > Current Status: > >We working currently on Firefox 3.6 (alpha1) [2], Thunderbird 3.0 > > (beta3) [1], > >new libxul 1.9.1.2. All 3 are already committed to our repo. > > > > [1] a screenshot from tb3 under FreeBSD > > http://tmp.chruetertee.ch/tb3.0b3.png > > [2] a screenshot from ff36 under FreeBSD > > http://tmp.chruetertee.ch/ff36.png > > > > A current status can you find here: > >https://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO > > > > > > So that's all at the moment, Feedback, Comments are welcome. > > > > - Martin for the FreeBSD Gecko Team > > > > > ___ > freebsd-gn...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-gnome > To unsubscribe, send any mail to "freebsd-gnome-unsubscr...@freebsd.org" > > > I just have one question when has xulrunner been unsupported upstream > > considering that xulrunner 1.9.1 was released when firefox 3.5.2 was teh > > last release of xulrunner 1.9.x alpha was august 22end yes it's > development > > but it's still supported. upstream > > ___ > > 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" > > > Hi, > > I think he means www/xulrunner, based on 1.8.0 > (http://www.freshports.org/www/xulrunner/) is no longer supported und > should get removed from the tree. > Your mentioned xulrunner 1.9.x is still supported and inside the > ports-tree under www/libxul, which will not get removed. > (http://www.freshports.org/www/libxul/) > > /BR > > Ah ok since I know that libxul is a single library. hence why I got a bit confused since I knew xulrunner is still supported jsut not 1.8.x ___ 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: [HEADUP] FreeBSD Gecko's TODO and plan for future
On Sat, Aug 22, 2009 at 2:22 PM, Martin Wilke wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Howdy Guys, > > The FreeBSD Gecko Team will let you know what the plans for > the future are and on what we are currently working. > > Goals: > * Removal of mozilla, nvu, xulrunner and firefox2. > * www/firefox35 should be moved to www/firefox. > * The options USE_GECKO mozilla nvu xulrunner and firefox will be also > removed. > > Background: > We have a lot of old stuff on the portstree and it's time to cleanup old > stuff. > * www/mozilla is 5 year old now, no longer supported by upstream, and > has many many vulnerabilities. We can use www/seamonkey. > > * www/nvu last official release was in 2005, no longer supported, and > also some vulnerabilities. We have www/kompozer which also need an > update to get this unbroken. > > * www/xulrunner is old and was replaced by www/libxul. We should not > hold any old Gecko stuff. Also it's not longer supported by upstream: > https://wiki.mozilla.org/XULRunner:Roadmap > > Problems which we have to solve: > Some Gnome ports need www/firefox to build and work, but unfortunately > firefox2 isn't longer supported by the Mozilla Foundation. Also > www/firefox has a lot of vulnerabilities. We should www/firefox > mark FORBIDDEN at this time gives no fixes for the latest securtiy > reports. > > We see here 2 ways: > 1) The Gnome Team (not the FreeBSD Gnome Team) take time and move all > his > stuff to libxul. > 2) or we the FreeBSD Team have to remove all these ports. We know > that's > really hard but we should not hold vulnerabilities stuff. > > We hope to get here a bit help from the FreeBSD Gnome Team to make it > possible to get some stuff to work with the current libxul version. > > Current Status: >We working currently on Firefox 3.6 (alpha1) [2], Thunderbird 3.0 > (beta3) [1], >new libxul 1.9.1.2. All 3 are already committed to our repo. > > [1] a screenshot from tb3 under FreeBSD > http://tmp.chruetertee.ch/tb3.0b3.png > [2] a screenshot from ff36 under FreeBSD > http://tmp.chruetertee.ch/ff36.png > > A current status can you find here: >https://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO > > > So that's all at the moment, Feedback, Comments are welcome. > > - - Martin for the FreeBSD Gecko Team > > > - -- > > +---+---+ > | PGP: 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | > | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | > +---+---+ > | Mess with the Best, Die like the Rest! | > +---+---+ > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAkqQN08ACgkQdLJIhLHm/OlZ7wCgk6xG3ymevRMf1D/0e9LpEqZ4 > vF8An200XdohvNq3nptL4NCBIom+vgPN > =SlKU > -END PGP SIGNATURE- > ___ > freebsd-gn...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-gnome > To unsubscribe, send any mail to "freebsd-gnome-unsubscr...@freebsd.org" I just have one question when has xulrunner been unsupported upstream considering that xulrunner 1.9.1 was released when firefox 3.5.2 was teh last release of xulrunner 1.9.x alpha was august 22end yes it's development but it's still supported. upstream ___ 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: make package broken for multimedia/gstreamer
On Sun, Aug 9, 2009 at 1:20 PM, Koop Mast wrote: > On Sun, 2009-08-09 at 18:19 +0200, Raphael Becker wrote: > > Hi there, > > > > is this just a local problem (cvsup failed) or is this a general > > problem with multimedia/gstreamer? > > > > TIA > > Raphael Becker > > Check your libtool and libltdl. You should have version 2.2.6(a) > installed. Read ports/UPDATING for more info about the libtool update. > > -Koop > > > > > [r...@freebsd /usr/ports/multimedia/gstreamer]# ls -la > > total 26 > > drwxr-xr-x3 root wheel 512 Aug 5 17:41 . > > drwxr-xr-x 307 root wheel 6656 Aug 7 21:41 .. > > -rw-r--r--1 root wheel 1746 Aug 5 17:41 Makefile > > -rw-r--r--1 root wheel 212 Aug 5 17:41 distinfo > > drwxr-xr-x2 root wheel 512 Aug 5 17:41 files > > -rw-r--r--1 root wheel 1057 Jul 15 2002 pkg-descr > > -rw-r--r--1 root wheel 7656 Aug 5 17:41 pkg-plist > > > > > > # make package > > [...] > > ===> Registering installation for gstreamer-0.10.24 > > ===> Building package for gstreamer-0.10.24 > > Creating package /usr/ports/packages/All/gstreamer-0.10.24.tbz > > Registering depends: gio-fam-backend-2.20.4 gamin-0.1.10_3 glib-2.20.4 > popt-1.14 gettext-0.17_1 libxml2-2.7.3 libiconv-1.13.1 libcheck-0.9.6 > libXv-1.0.4,1 libXext-1.0.5,1 libX11-1.2.1_1,1 libxcb-1.4 > libpthread-stubs-0.1 pcre-7.9 libXau-1.0.4 libXdmcp-1.0.2_1 xproto-7.0.15 > pkg-config-0.23_1 perl-threaded-5.8.9_3 xcb-proto-1.5 python26-2.6.2_1 > kbproto-1.0.3 videoproto-2.2.2 xextproto-7.0.5. > > Creating bzip'd tar ball in > '/usr/ports/packages/All/gstreamer-0.10.24.tbz' > > tar: lib/libgstbase-0.10.so.0: Cannot stat: No such file or directory > > tar: lib/libgstcheck-0.10.so.0: Cannot stat: No such file or directory > > tar: lib/libgstcontroller-0.10.so.0: Cannot stat: No such file or > directory > > tar: lib/libgstdataprotocol-0.10.so.0: Cannot stat: No such file or > directory > > tar: lib/libgstnet-0.10.so.0: Cannot stat: No such file or directory > > tar: lib/libgstreamer-0.10.so.0: Cannot stat: No such file or directory > > tar: Error exit delayed from previous errors. > > pkg_create: make_dist: tar command failed with code 256 > > *** Error code 1 > > > > Stop in /usr/ports/multimedia/gstreamer. > > > > > > # ls -la /usr/local/lib/libgst* > > -rw-r--r-- 1 root wheel 797764 Aug 9 18:11 > /usr/local/lib/libgstbase-0.10.a > > -rwxr-xr-x 1 root wheel 1167 Aug 9 18:11 /usr/local/lib/ > libgstbase-0.10.la > > lrwxr-xr-x 1 root wheel 21 Aug 9 18:11 /usr/local/lib/ > libgstbase-0.10.so -> libgstbase-0.10.so.21 > > -rwxr-xr-x 1 root wheel 562108 Aug 9 18:11 > /usr/local/lib/libgstbase-0.10.so.21 > > -rw-r--r-- 1 root wheel 103482 Aug 9 18:11 > /usr/local/lib/libgstcheck-0.10.a > > -rwxr-xr-x 1 root wheel 1201 Aug 9 18:11 /usr/local/lib/ > libgstcheck-0.10.la > > lrwxr-xr-x 1 root wheel 22 Aug 9 18:11 /usr/local/lib/ > libgstcheck-0.10.so -> libgstcheck-0.10.so.21 > > -rwxr-xr-x 1 root wheel75151 Aug 9 18:11 > /usr/local/lib/libgstcheck-0.10.so.21 > > -rw-r--r-- 1 root wheel 520480 Aug 9 18:11 > /usr/local/lib/libgstcontroller-0.10.a > > -rwxr-xr-x 1 root wheel 1209 Aug 9 18:11 /usr/local/lib/ > libgstcontroller-0.10.la > > lrwxr-xr-x 1 root wheel 27 Aug 9 18:11 /usr/local/lib/ > libgstcontroller-0.10.so -> libgstcontroller-0.10.so.21 > > -rwxr-xr-x 1 root wheel 398526 Aug 9 18:11 > /usr/local/lib/libgstcontroller-0.10.so.21 > > -rw-r--r-- 1 root wheel42652 Aug 9 18:11 > /usr/local/lib/libgstdataprotocol-0.10.a > > -rwxr-xr-x 1 root wheel 1223 Aug 9 18:11 /usr/local/lib/ > libgstdataprotocol-0.10.la > > lrwxr-xr-x 1 root wheel 29 Aug 9 18:11 /usr/local/lib/ > libgstdataprotocol-0.10.so -> libgstdataprotocol-0.10.so.21 > > -rwxr-xr-x 1 root wheel38512 Aug 9 18:11 > /usr/local/lib/libgstdataprotocol-0.10.so.21 > > -rw-r--r-- 1 root wheel88106 Aug 9 18:11 > /usr/local/lib/libgstnet-0.10.a > > -rwxr-xr-x 1 root wheel 1160 Aug 9 18:11 /usr/local/lib/ > libgstnet-0.10.la > > lrwxr-xr-x 1 root wheel 20 Aug 9 18:11 /usr/local/lib/ > libgstnet-0.10.so -> libgstnet-0.10.so.21 > > -rwxr-xr-x 1 root wheel64612 Aug 9 18:11 > /usr/local/lib/libgstnet-0.10.so.21 > > -rw-r--r-- 1 root wheel 3242574 Aug 9 18:11 > /usr/local/lib/libgstreamer-0.10.a > > -rwxr-xr-x 1 root wheel 1145 Aug 9 18:11 /usr/local/lib/ > libgstreamer-0.10.la > > lrwxr-xr-x 1 root wheel 23 Aug 9 18:11 /usr/local/lib/ > libgstreamer-0.10.so -> libgstreamer-0.10.so.21 > > -rwxr-xr-x 1 root wheel 2130698 Aug 9 18:11 > /usr/local/lib/libgstreamer-0.10.so.21 > > > > > > -- > > Raphael Beckerhttp://rabe.uugrn.org/ > > https://www.xing.com/profile/Raphael_Becker > > GnuPG:E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D > > .|.|.|.|.|.|.|.. > > > __
Re: What does py25 mean?
On Tue, Aug 4, 2009 at 4:48 PM, Lars Eighner wrote: > What does py25 mean? > > I can't seem to upgrade about 40 ports (the old versions of which now seem > to be broken) evidently because the build of > > py25-gtk-2.13.1 fails with the message > >py25-cairo-1.8.6 needs Python 2.6 at least. But you specified 2.5. > > Well, of *I* did not specify 2.5. > > But howcome something called py25-cairo needs Python 2.6? What does that > py25 on the front mean? Doesn't it mean python 2.5? If it doesn't mean > that, what does it mean? If it does mean that, then howcome it needs > python > 2.6? > > > -- > Lars Eighner > http://www.larseighner.com/index.html > 8800 N IH35 APT 1191 AUSTIN TX 78753-5266 > > ___ > 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" > yes it means python 2.5 most likely for cairo the py25 was not bumped to py26 ___ 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: mplayer-0.99.11_14
On Tue, Jul 21, 2009 at 12:51 PM, Michael D. Stackhouse < mstackho...@samsa.com> wrote: > Is there an update available for mplayer? The current version at > http://www.mplayerhq.hu seems to imply a 1.0 version. > > We're having problems with this error, that is likely corrected in a > version greater than 0.99.11_14: > vmbsd02# /usr/local/bin/mencoder > rtsp://root:p...@172.28.10.65/mpeg4/media.amp -ovc copy -o > /tmp/mike.mpeg4 > MEncoder 1.0rc2-4.2.1 (C) 2000-2007 MPlayer Team > CPU: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz (Family: 6, Model: > 26, Stepping: 8) > CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 > Compiled with runtime CPU detection. > Connecting to server 172.28.10.65[172.28.10.65]: 554... > librtsp: server responds: 'RTSP/1.0 401 Unauthorized' > rtsp_session: unsupported RTSP server. Server type is 'unknown'. > STREAM_LIVE555, URL: rtsp://root:p...@172.28.10.65/mpeg4/media.amp > success: format: 21 data: 0x0 - 0x0 > Stream not seekable! > file format detected. > Initiated "video/MP4V-ES" RTP subsession on port 51198 > VIDEO: [mp4v] 0x0 0bpp 6.000 fps0.0 kbps ( 0.0 kbyte/s) > [V] filefmt:21 fourcc:0x7634706D size:0x0 fps: 6.00 ftime:=0.1667 > videocodec: framecopy (0x0 0bpp fourcc=7634706d) > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size > exceeds the client's buffer size (5). 1100 bytes of trailing data > will be dropped! > Saw an input frame too large (>=5). Increase MAX_RTP_FRAME_SIZE in > "demux_rtp.cpp". > Writing header... > ODML: Aspect information not (yet?) available or unspecified, not > writing vprp header. > Writing header... > ODML: Aspect information not (yet?) available or unspecified, not > writing vprp header. > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size > exceeds the client's buffer size (5). 1100 bytes of trailing data > will be dropped! > Saw an input frame too large (>=5). Increase MAX_RTP_FRAME_SIZE in > "demux_rtp.cpp". > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size > exceeds the client's buffer size (5). 1100 bytes of trailing data > will be dropped! > Saw an input frame too large (>=5). Increase MAX_RTP_FRAME_SIZE in > "demux_rtp.cpp". > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size > exceeds the client's buffer size (5). 1100 bytes of trailing data > will be dropped! > Saw an input frame too large (>=5). Increase MAX_RTP_FRAME_SIZE in > "demux_rtp.cpp". > MultiFramedRTPSource::doGetNextFrame1(): The total received frame size > exceeds the client's buffer size (5). 1100 bytes of trailing data > will be dropped! > Saw an input frame too large (>=5). Increase MAX_RTP_FRAME_SIZE in > "demux_rtp.cpp". > > Any suggestions would be appreciated. > > Thanks! > > Michael D. Stackhouse > SAMSA, Inc. > 989-790-0507 > Saginaw, MI USA > www.samsa.com > > > > > samsaisgreat > > > ___ > 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" Considering that mplayer no longer does stable releases you would have to switch the makefile to use svn to get an updated mplayer ___ 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: vim ports broken.
On Mon, Jun 22, 2009 at 6:23 PM, Carlos A. M. dos Santos < unixma...@gmail.com> wrote: > On Mon, Jun 22, 2009 at 4:58 PM, Philip M. Gollucci > wrote: > > Helmut Schneider wrote: > >> > >> matt donovan wrote: > >>> > >>> On Fri, Jun 19, 2009 at 5:37 AM, Albert Shih > >>> wrote: > >>>> > >>>> I think the vim ports is broken. > >>> > >>> Nope not broken just takes a long time to grab that patch since it > pulls > >>> from FreeBSD ftp localdistfiles mirror under obrien > >> > >> The port *is* broken: > >> > >> # fetch > >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041% > >> fetch: > >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041%: > Bad > >> Request > >> # > >> > >> as fetch cannot handle "%" correctly. > > > > sure it can, it just needs '' around the url. > > The distinfo file is wrong. Edit it and put the correct data for that > patch: > > MD5 (vim/7.2.041) = 66bde35426c09d9c666e23215f9a19c9 > SHA256 (vim/7.2.041) = > 524aa9aeb9f8729fb91289f40a4c5fecf5d0d07d3655c4a38a65abc98f7cd71b > SIZE (vim/7.2.041) = 22993 > > Be warned that your mail agent (or mine) may break the second line > after the equal sign. > > David, could you please commit this fix? > > -- > My preferred quotation of Robert Louis Stevenson is "You cannot > make an omelette without breaking eggs". Not because I like the > omelettes, but because I like the sound of eggs being broken. > ___ > 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" > I have had no problem grabbing the patch from the local-distfiles. just takes a very long time of course though to get to the right mirror ___ 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: vim ports broken.
On Fri, Jun 19, 2009 at 6:59 PM, matt donovan wrote:
>
>
> On Fri, Jun 19, 2009 at 5:37 AM, Albert Shih wrote:
>
>> Hi all
>>
>> I think the vim ports is broken.
>>
>> When I try to compile I've got :
>>
>> [root@ vim]# make
>> ===> Vulnerability check disabled, database not found
>> => 7.2.041% doesn't seem to exist in /usr/ports/distfiles/vim.
>> => Attempting to fetch from http://ftp.vim.org/pub/vim/patches/7.2/.
>> fetch: http://ftp.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
>> => Attempting to fetch from
>> http://mirrors.24-7-solutions.net/pub/vim/patches/7.2/.
>> fetch: http://mirrors.24-7-solutions.net/pub/vim/patches/7.2/7.2.041%:
>> Bad
>> Request
>> => Attempting to fetch from http://ftp.tw.vim.org/pub/vim/patches/7.2/.
>> fetch: http://ftp.tw.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
>> => Attempting to fetch from http://vim.stu.edu.tw/patches/7.2/.
>> fetch: http://vim.stu.edu.tw/patches/7.2/7.2.041%: Not Found
>> => Attempting to fetch from http://gd.tuwien.ac.at/pub/vim/patches/7.2/.
>> fetch: http://gd.tuwien.ac.at/pub/vim/patches/7.2/7.2.041%: Bad Request
>> => Attempting to fetch from
>> http://www.etsimo.uniovi.es/pub/vim/patches/7.2/.
>> fetch: http://www.etsimo.uniovi.es/pub/vim/patches/7.2/7.2.041%: Bad
>> Request
>> => Attempting to fetch from http://www.pt.vim.org/pub/vim/patches/7.2/.
>> fetch: http://www.pt.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
>> => Attempting to fetch from
>> http://www.pangora.org/vim.org/pub/vim/patches/7.2/.
>>
>> I don't known the purpose of last line of
>>
>># bits to remove
>>BADPATCHES= 007 036 049 071 072 074 088 089 093 101 138 150 172
>> 191 194
>>204 205
>>#.if !defined(WITH_LANG)
>>#BADPATCHES+=
>>#.endif
>>.for p in ${BADPATCHES}
>>PATCHFILES:=${PATCHFILES:N7.2.${p}}
>>.endfor
>>PATCHFILES:=${PATCHFILES:S/041/041%/}
>>
>> but it seem strange for me...
>>
>> Thanks the work.
>>
>> Regards.
>>
>
Here is the path to the patch file
ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/obrien/7.2.041%
___
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: vim ports broken.
On Fri, Jun 19, 2009 at 5:37 AM, Albert Shih wrote:
> Hi all
>
> I think the vim ports is broken.
>
> When I try to compile I've got :
>
> [root@ vim]# make
> ===> Vulnerability check disabled, database not found
> => 7.2.041% doesn't seem to exist in /usr/ports/distfiles/vim.
> => Attempting to fetch from http://ftp.vim.org/pub/vim/patches/7.2/.
> fetch: http://ftp.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
> => Attempting to fetch from
> http://mirrors.24-7-solutions.net/pub/vim/patches/7.2/.
> fetch: http://mirrors.24-7-solutions.net/pub/vim/patches/7.2/7.2.041%: Bad
> Request
> => Attempting to fetch from http://ftp.tw.vim.org/pub/vim/patches/7.2/.
> fetch: http://ftp.tw.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
> => Attempting to fetch from http://vim.stu.edu.tw/patches/7.2/.
> fetch: http://vim.stu.edu.tw/patches/7.2/7.2.041%: Not Found
> => Attempting to fetch from http://gd.tuwien.ac.at/pub/vim/patches/7.2/.
> fetch: http://gd.tuwien.ac.at/pub/vim/patches/7.2/7.2.041%: Bad Request
> => Attempting to fetch from
> http://www.etsimo.uniovi.es/pub/vim/patches/7.2/.
> fetch: http://www.etsimo.uniovi.es/pub/vim/patches/7.2/7.2.041%: Bad
> Request
> => Attempting to fetch from http://www.pt.vim.org/pub/vim/patches/7.2/.
> fetch: http://www.pt.vim.org/pub/vim/patches/7.2/7.2.041%: Bad Request
> => Attempting to fetch from
> http://www.pangora.org/vim.org/pub/vim/patches/7.2/.
>
> I don't known the purpose of last line of
>
># bits to remove
>BADPATCHES= 007 036 049 071 072 074 088 089 093 101 138 150 172
> 191 194
>204 205
>#.if !defined(WITH_LANG)
>#BADPATCHES+=
>#.endif
>.for p in ${BADPATCHES}
>PATCHFILES:=${PATCHFILES:N7.2.${p}}
>.endfor
>PATCHFILES:=${PATCHFILES:S/041/041%/}
>
> but it seem strange for me...
>
> Thanks the work.
>
> Regards.
>
>
>
> --
>
Nope not broken just takes a long time to grab that patch since it pulls
from FreeBSD ftp localdistfiles mirror under obrien
___
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: nessus-2.2.9_1
On Tue, Jun 16, 2009 at 7:21 PM, Alexey Shuvaev < shuv...@physik.uni-wuerzburg.de> wrote: > On Tue, Jun 16, 2009 at 07:07:12PM -0400, matt donovan wrote: > > On Tue, Jun 16, 2009 at 1:39 PM, Schweigert, Udo CERT < > > udo.schweig...@siemens.com> wrote: > > > > > No, there are no further updates as 2.2.9 is the last open source > version. > > > > > > Udo > > > > > > On Tue, Jun 16, 2009 at 12:16:54 -0500, > phillip.gonza...@metavante.comwrote: > > > > > > > > hi, > > > > > > > > i'm looking at the nessus port on one of my FreeBSD boxes(recently > > > updated > > > > ports tree) and it looks like it's at version 2.2.9. has this port > not > > > > been updated or am i missing something? > > > > > > > > thanks for your time, > > > > > > > > Phillip P Gonzalez > > > > Information Security Analyst Sr. > > > > Security Analysis and Testing > > > > Metavante Corporation > > > > tel: 414.357.3156 > > > > > > > > > > > > > > > You have to go to the nessus website to grab the package now since it's > no > > longer open source > > > I don't use nessus myself but just checking their website I see 2.2.11 > as the latest open source version. > > Just 0.02$, > Alexey. yes which is out of date anyways might as well just grab the freebsd package ___ 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: nessus-2.2.9_1
On Tue, Jun 16, 2009 at 1:39 PM, Schweigert, Udo CERT < udo.schweig...@siemens.com> wrote: > No, there are no further updates as 2.2.9 is the last open source version. > > Udo > > On Tue, Jun 16, 2009 at 12:16:54 -0500, phillip.gonza...@metavante.comwrote: > > > > hi, > > > > i'm looking at the nessus port on one of my FreeBSD boxes(recently > updated > > ports tree) and it looks like it's at version 2.2.9. has this port not > > been updated or am i missing something? > > > > thanks for your time, > > > > Phillip P Gonzalez > > Information Security Analyst Sr. > > Security Analysis and Testing > > Metavante Corporation > > tel: 414.357.3156 > > > > > You have to go to the nessus website to grab the package now since it's no longer open source ___ 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: what does this mean?
On Sat, Jun 6, 2009 at 10:03 AM, dan hirsch wrote: > 1. > > Running the csup(1)< > http://www.freebsd.org/cgi/man.cgi?query=csup&sektion=1>command > later will download and apply all the recent changes to your Ports > Collection, except actually rebuilding the ports for your own system. > > > > -- > regards, > Dan Hirsch > Linked-In: http://www.linkedin.com/in/danhirsch1 > ___ > 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" > exactly as it states it will update your port tree but will not rebuild and install ports that need updating. ___ 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: Make package-recursive problem
It should be under the following circumstances: - You don't update /usr/ports I haven't. - You don't change /etc/make.conf I haven't. - You don't deinstall packages I haven't. =) The "bug" I'm describing would make sense if SOMETHING changed. But I haven't changed a thing. ___ 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: Make package-recursive problem
I have no clue as to what is causing this, but this is probably the reason why people use the tinderbox or roll their own system to build consistent packages. I feel like I am though? I have a dedicated box just for building packages. make package creates a tbz file of all packages, and is supposed to be reliable. Another approach had even the package dependency inside a Makefile, so rebuilding the gettext package would trigger all dependent packages to get rebuilt too (I haven't tackled the problem of *reinstalling* them on the target hosts, though) Doesn't this already occur with the default tools in the port system? ___ 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 package-recursive problem
Hi all, I've started noticing more and more that packages I build are missing files after they are rebuilt. I've tested this time and time again, and seem to be able to show that about 10 ports (gettext, apache, net-snmp, some php modules, etc.) are built correctly the first time, but when later re-packaged, do not contain all the files they need. For instance, I have a build box (named atlantis for the sake of this email): on atlantis, I build all packages with make package-recursive, and then install them on all boxes via NFS. This works fine, except that over time, as I compile more packages, the ports system re-generates packages for existing built packages (for instance, if I make a nagios package, it recreates the apache package since that's a dependency. If I then install cacti, it recreates the apache package again). This is normally no big deal, as I haven't touched my source tree, config options, or anything like that. 99% of the time the packages are rebuilt consistently. However, since this point, I've had some php modules come up empty (as in my original email), and now, I'm having some other flukes as well. If you'll see below, somehow, fontconfig, mysql-client, and python25 got out of whack between my build box and a production webserver. Yet these are packages built from the same environment - same box, same config, same tree, etc. - I didn't change a thing, other than install them at different times. But my build tree on atlantis has not been updated or changed in any manor. This obviously occured because make package-recursive rebuilt these packages at some point because they were dependencies for other packages being installed. Except that, obviously, it didn't build the packages 100% identically to the time before: local$ sh check2.sh barfy -> fontconfig-2.6.0,1 isn't right barfy -> mysql-client-5.0.77_1 isn't right barfy -> python25-2.5.4_1 isn't right local$ sh check3.sh Server 1: atlantis Server 2: barfy Package: fontconfig Password: Password: 65,67d64 < /usr/local/share/doc/fontconfig/fontconfig-user.html < /usr/local/share/doc/fontconfig/fontconfig-user.pdf < /usr/local/share/doc/fontconfig/fontconfig-user.txt Here's an example of how to replicate: - Create and install net-snmp package on box1 and box2 - Set make.conf options for apache2 - Create a nagios package (cd /usr/ports/.../nagios && make package-recursive) - Install the nagios package on box1 - Create a cacti package (cd /usr/ports/.../cacti && make package-recursive) - Install the cacti package on box2 What you'll now most likely find is that there are package differences between the two boxes in the SNMP and apache package. One of the boxes (most likely box2) will be missing startup scripts for snmp because, when you created the cacti package, it re-created an apache package too, except that it didn't have all of the files. pkg_info -xL net-snmp will show two different result sets from each box, even though the net-snmp package was built from the same box. If you need me to, I can replicate this issue in actuality by pasting a command output showing the differences. Please let me know if that's needed. Thanks! -Matt ___ 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: screen and tmux should be listed under the same category
On Sun, May 17, 2009 at 7:43 PM, matt donovan wrote: > > > On Sun, May 17, 2009 at 2:37 AM, Freddie Cash wrote: > >> On Sat, May 16, 2009 at 4:38 PM, matt donovan >> wrote: >> > On Sat, May 16, 2009 at 5:53 PM, Philip M. Gollucci < >> pgollu...@p6m7g8.com>wrote: >> > >> >> Josh Rickmar wrote: >> >> > GNU screen is listed under sysutils, while tmux is listed under misc. >> >> > Shouldn't the two at least be in the same category, since they both >> do >> >> > the exact same thing? (tmux is even designed to be a BSD-licensed >> >> > replacement for screen.) >> >> > >> >> Does anyone have any thoughts on tmux vs screen ? the NO_PACKAGE in >> >> screen has been annoying me for years now if I can find a good >> >> replacement I'm so there. >> >> >> > tmux does not work inside the shell due to sc. But in X it works >> wonders. >> >> tmux works just fine at a console without X running. >> >> >> > hmm odd since last time I asked about it it did not since I m the one that > brought it up, since I had an error and was told that the sc does not > support that feature what freebsd are you running since I tired it in 7.x. > forgot something unless of coruse your using a term change trick that I suggested to the author of tmux. ___ 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: screen and tmux should be listed under the same category
On Sun, May 17, 2009 at 2:37 AM, Freddie Cash wrote: > On Sat, May 16, 2009 at 4:38 PM, matt donovan > wrote: > > On Sat, May 16, 2009 at 5:53 PM, Philip M. Gollucci < > pgollu...@p6m7g8.com>wrote: > > > >> Josh Rickmar wrote: > >> > GNU screen is listed under sysutils, while tmux is listed under misc. > >> > Shouldn't the two at least be in the same category, since they both do > >> > the exact same thing? (tmux is even designed to be a BSD-licensed > >> > replacement for screen.) > >> > > >> Does anyone have any thoughts on tmux vs screen ? the NO_PACKAGE in > >> screen has been annoying me for years now if I can find a good > >> replacement I'm so there. > >> > > tmux does not work inside the shell due to sc. But in X it works > wonders. > > tmux works just fine at a console without X running. > > > hmm odd since last time I asked about it it did not since I m the one that brought it up, since I had an error and was told that the sc does not support that feature what freebsd are you running since I tired it in 7.x. ___ 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: screen and tmux should be listed under the same category
On Sat, May 16, 2009 at 5:53 PM, Philip M. Gollucci wrote: > Josh Rickmar wrote: > > GNU screen is listed under sysutils, while tmux is listed under misc. > > Shouldn't the two at least be in the same category, since they both do > > the exact same thing? (tmux is even designed to be a BSD-licensed > > replacement for screen.) > > > Does anyone have any thoughts on tmux vs screen ? the NO_PACKAGE in > screen has been annoying me for years now if I can find a good > replacement I'm so there. > > > tmux does not work inside the shell due to sc. But in X it works wonders. ___ 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: Please update devel/boost
If you look On Fri, May 1, 2009 at 11:02 AM, cpghost wrote: > devel/boost is currently at 1.37.0, while the upstream is > at 1.38.0 (since 2009-02-09 01:36). If you have some time, > please update the port. > > Thank you. > -cpghost. > > -- > Cordula's Web. http://www.cordula.ws/ > ___ > 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" If you look there has been an update to boost it takes time to update such a big port hence why it's not in the tree fully yet ___ 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"
