Re: BIND REPLACE_BASE option
The dialog option you talk about says: [ ] REPLACE_BASEEOL, no longer supported I'm quite sure the end-user you're talking about can get a clue from it, and if he either already had selected it before, or he just selected it, he will get: === bind99-9.9.6P1_3 REPLACE_BASE is no longer supported. The end-user can then get another clue and maybe unselect it. Maybe you're right but, to perhaps better illustrate the point, you would never see something like this in Ubuntu, Debian, Redhat, or SuSE. Roger ___ 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 01/13/15 20:11, Roger Marquis wrote: The dialog option you talk about says: [ ] REPLACE_BASEEOL, no longer supported I'm quite sure the end-user you're talking about can get a clue from it, and if he either already had selected it before, or he just selected it, he will get: === bind99-9.9.6P1_3 REPLACE_BASE is no longer supported. The end-user can then get another clue and maybe unselect it. Maybe you're right but, to perhaps better illustrate the point, you would never see something like this in Ubuntu, Debian, Redhat, or SuSE. I agree but lets back out just a bit. This fundamentally sound pkg infrastructure is very new to FreeBSD, and it completely rocks. As much as I grit my teeth over certain road bumps I have to acknowledge that local customizable binary repos... well that's fantastic. But that's the infrastructure. People take time to learn what having such an infrastructure really means in terms of the expectations of developers looking toward users, and users looking into packages (and not necessarily caring if a developer even exists). It took a very long time for those linux distros to get their pkg upgrade process as smooth as it is now, and a large part of that time was spent acculterating the individual pkg maintainers (an evolving population) into the idea that an installed pkg should continue to just work if it already does. If it can't continue to just work, then there are lots of handholding instructions suitable for very stupid people generally provided, as barriers, during the upgrade process. All that extra packaging effort is devoted by far to the clueless (sometimes willfully clueless) fraction of the luser base. It's apparent that the FreeBSD community in the main does not have that mentality now. It's part of the attraction, to be clear, myself included. But now with superb package management capabilities in place, I think we will see, over a decade or so, the same sort of smoothness that the best linux distros display gradually emerge in FreeBSD. Craig R is a hero here. In the meantime I'm going to be trying harder to cut the pkg maintainers more slack. It's a sometimes hard, mostly thankless job that is absolutely crucial. 2c, Russell Roger ___ 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: BIND REPLACE_BASE option
On Tue, 13 Jan 2015 19:11:50 -0800 (PST) Roger Marquis marq...@roble.com wrote The dialog option you talk about says: [ ] REPLACE_BASEEOL, no longer supported I'm quite sure the end-user you're talking about can get a clue from it, and if he either already had selected it before, or he just selected it, he will get: === bind99-9.9.6P1_3 REPLACE_BASE is no longer supported. The end-user can then get another clue and maybe unselect it. Maybe you're right but, to perhaps better illustrate the point, you would never see something like this in Ubuntu, Debian, Redhat, or SuSE. Honestly. Need I remind you, this is FreeBSD, *not* Linux? In all honesty, I am *not* pleased with the current efforts to turn the FreeBSD motto The Power to Serve into FreeBSD, it's the new Linux. But I [begrudgingly] understand the inclination to do so. That said. While I understand your inclination to think FreeBSD must somehow be broken, when it doesn't operate as you're accustomed with Linux. This is FreeBSD, after all, and as hard as everyone works to eliminate the element of surprise, this is still FreeBSD. So celebrate the difference. Don't curse it, or more importantly; it's hard working developers. :) --Chris Roger ___ 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: BIND REPLACE_BASE option
On Tue, Jan 13, 2015 at 7:15 PM, Chris H bsd-li...@bsdforge.com wrote: On Tue, 13 Jan 2015 19:11:50 -0800 (PST) Roger Marquis marq...@roble.com wrote The dialog option you talk about says: [ ] REPLACE_BASEEOL, no longer supported I'm quite sure the end-user you're talking about can get a clue from it, and if he either already had selected it before, or he just selected it, he will get: === bind99-9.9.6P1_3 REPLACE_BASE is no longer supported. The end-user can then get another clue and maybe unselect it. Maybe you're right but, to perhaps better illustrate the point, you would never see something like this in Ubuntu, Debian, Redhat, or SuSE. Honestly. Need I remind you, this is FreeBSD, *not* Linux? In all honesty, I am *not* pleased with the current efforts to turn the FreeBSD motto The Power to Serve into FreeBSD, it's the new Linux. But I [begrudgingly] understand the inclination to do so. The Power to Serve can only be brought to bear if a small-shop sysadmin isn't afraid to touch their ports. That said. While I understand your inclination to think FreeBSD must somehow be broken, when it doesn't operate as you're accustomed with Linux. This is FreeBSD, after all, and as hard as everyone works to eliminate the element of surprise, this is still FreeBSD. So celebrate the difference. Don't curse it, or more importantly; it's hard working developers. :) None of this is intended to disparage the teams. Royce ___ 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/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 10:08:05 -0800 Freddie Cash fjwc...@gmail.com wrote Good morning, With the requirement for the NONE cipher in OpenSSH requiring a custom compile of the world or a custom compile of the openssh-portable port (all my production servers are binary-package-only now), I've started using bbcp instead of zfs send over SSH. And looking at using bbcp instead of rsync over SSH for another system (transfer speed is more important than encrypting the data as the transfer is done over a very local LAN link). The bbcp port is version 20120520; the latest version available is 20140902. There have been several new features added over the past 2 years that make it (at least on paper) a decent rsync replacement for our uses. Is there anyone interested in bringing this port up-to-date. I had a quick look, but it requires some C hacking that's beyond my skills. :( I've only tried compiling it with clang, which gives lots of errors. Haven't tried with gcc, though. I just had a look. Looks interesting. I can't foresee any issue moving it ahead. But before I step up, and say I'll take it. Have you contacted the maintainer? I don't want to step on any toes. :) --Chris I have 3 FreeBSD 9.3 systems that transfer data to a 4th FreeBSD 9.3 system using zfs send over bbcp that can be used for testing things. As well as a Debian 7.0 box that can be tested for pulling data off a FreeBSD system. I'd prefer to not install the ports tree on any of the production systems, but I could spin up a KVM-based VM if needed. -- Freddie Cash fjwc...@gmail.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 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
sysutils/bbcp: Anyone interesting in helping upgrade this port?
Good morning, With the requirement for the NONE cipher in OpenSSH requiring a custom compile of the world or a custom compile of the openssh-portable port (all my production servers are binary-package-only now), I've started using bbcp instead of zfs send over SSH. And looking at using bbcp instead of rsync over SSH for another system (transfer speed is more important than encrypting the data as the transfer is done over a very local LAN link). The bbcp port is version 20120520; the latest version available is 20140902. There have been several new features added over the past 2 years that make it (at least on paper) a decent rsync replacement for our uses. Is there anyone interested in bringing this port up-to-date. I had a quick look, but it requires some C hacking that's beyond my skills. :( I've only tried compiling it with clang, which gives lots of errors. Haven't tried with gcc, though. I have 3 FreeBSD 9.3 systems that transfer data to a 4th FreeBSD 9.3 system using zfs send over bbcp that can be used for testing things. As well as a Debian 7.0 box that can be tested for pulling data off a FreeBSD system. I'd prefer to not install the ports tree on any of the production systems, but I could spin up a KVM-based VM if needed. -- Freddie Cash fjwc...@gmail.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/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 18:34:45 -0800 Chris H bsd-li...@bsdforge.com wrote On Tue, 13 Jan 2015 13:54:56 -0700 John Hein john.h...@microsemi.com wrote Kurt Jaeger wrote at 20:29 +0100 on Jan 13, 2015: I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I don't think he will (as can be seen from PR 192405). Provide a PR with the patch and I'll commit it after testing the build. I'll update it if no one else gets to it this week or review a PR. Thanks for the offer, and reply, John. So far I've squashed ~20 errors. I'm now at the IPv6 specific ones. Willing to hand it over if someone wants it. Thanks, John. I might just take you up on that. :) Thanks again, John. OK. All the errors have been chased, and crushed. But it's now late. So I won't be submitting the pr(1) until tomorrow. --Chris --Chris ___ 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 ___ 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/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 20:23:09 +0100 Mark Martinec mark.martinec+free...@ijs.si wrote Chris H wrote: I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I had an open request to upgrade sysutils/bbcp since August 2014, apparently the maintainer is absent or not interested. [Bug 192405] Please upgrade sysutils/bbcp, current version does not support IPv6 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192405 Ouch! Since *August*? Looks like the maintainer's otherwise occupied. I'm on it. I'll submit a new pr(1) when I'm done, and append a note to your previous one, as well. --Chris It would be very nice to bring it up-to-date. Mark ___ 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: sysutils/bbcp: Anyone interesting in helping upgrade this port?
Hi! I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I don't think he will (as can be seen from PR 192405). Provide a PR with the patch and I'll commit it after testing the build. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ 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/bbcp: Anyone interesting in helping upgrade this port?
On Tue, Jan 13, 2015 at 10:17 AM, Chris H bsd-li...@bsdforge.com wrote: On Tue, 13 Jan 2015 10:08:05 -0800 Freddie Cash fjwc...@gmail.com wrote Good morning, With the requirement for the NONE cipher in OpenSSH requiring a custom compile of the world or a custom compile of the openssh-portable port (all my production servers are binary-package-only now), I've started using bbcp instead of zfs send over SSH. And looking at using bbcp instead of rsync over SSH for another system (transfer speed is more important than encrypting the data as the transfer is done over a very local LAN link). The bbcp port is version 20120520; the latest version available is 20140902. There have been several new features added over the past 2 years that make it (at least on paper) a decent rsync replacement for our uses. Is there anyone interested in bringing this port up-to-date. I had a quick look, but it requires some C hacking that's beyond my skills. :( I've only tried compiling it with clang, which gives lots of errors. Haven't tried with gcc, though. I just had a look. Looks interesting. I can't foresee any issue moving it ahead. But before I step up, and say I'll take it. Have you contacted the maintainer? I don't want to step on any toes. :) Well, now I feel sheepish. I was looking at the freshports.org page for it and just saw portmgr-related commits to the port and assumed it was maintained by freebsd-ports (aka not maintained). I completely missed the little Maintainer line at the top. :( I've CC'd the port Maintainer to bring them into the loop. [Being a past port maintainer, I really should know better.] -- Freddie Cash fjwc...@gmail.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/bbcp: Anyone interesting in helping upgrade this port?
Chris H wrote: I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I had an open request to upgrade sysutils/bbcp since August 2014, apparently the maintainer is absent or not interested. [Bug 192405] Please upgrade sysutils/bbcp, current version does not support IPv6 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192405 It would be very nice to bring it up-to-date. Mark ___ 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/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 13:54:56 -0700 John Hein john.h...@microsemi.com wrote Kurt Jaeger wrote at 20:29 +0100 on Jan 13, 2015: I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I don't think he will (as can be seen from PR 192405). Provide a PR with the patch and I'll commit it after testing the build. I'll update it if no one else gets to it this week or review a PR. Thanks for the offer, and reply, John. So far I've squashed ~20 errors. I'm now at the IPv6 specific ones. Willing to hand it over if someone wants it. Thanks, John. I might just take you up on that. :) Thanks again, John. --Chris ___ 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: BIND REPLACE_BASE option
+--On 13 janvier 2015 15:39:47 -0800 Roger Marquis marq...@roble.com wrote: | Mathieu Arnold wrote: | Would you rather the port installing BIND in /usr/local without telling | you anything, silently breaking your installation completely ? | | Certainly not but it's unprofessional to present the end-user with a | dialog option that can be selected only to subsequently inform them that | the option is deprecated. It might take a little programming but the | error message printed when one port would overwrite files installed by | another would, IMO, be better i.e., recommending removal of the conflict | before installation. The dialog option you talk about says: [ ] REPLACE_BASEEOL, no longer supported I'm quite sure the end-user you're talking about can get a clue from it, and if he either already had selected it before, or he just selected it, he will get: === bind99-9.9.6P1_3 REPLACE_BASE is no longer supported. The end-user can then get another clue and maybe unselect it. Regards, -- Mathieu Arnold ___ 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: poudriere: reduce the number of rebuilt packages?
On Fri, Jan 02, 2015 at 12:03:54PM +0100, Stefan Ehmann wrote: I've recently switched from portmaster to poudriere/'pkg upgrade' to manage my port updates. Basically it works fine, but incremental builds don't quite work as I expected. poudriere rebuilds all packages if any dependency has changed. If there are only some ports with new versions, possibly hundreds of packages are rebuilt. So far it looks like I'll end up rebuilding packages like libreoffice/KDE/chromium several times a week. The rebuilt packages won't even be installed by 'pkg upgrade' because their version number has not changed. That's a huge waste of resources. With portmaster only ports with increased version numbers are rebuilt. Can I use poudriere to rebuild only packages where the version number changed? The problem here in consistency while in theory we can cherry-pick what we really want to rebuild based on libraries provided/required in binary packages poudriere has to deal with the ports tree and compatibility. The ports tree was a heavy user of pkg_add which became pkg add, this tool was relying on the version of dependencies as registered in the package creation: - A-v1 was depending on B-v2 if B-v2 is bumped to B-v3 then A-v1 dependency chain is broken in regard pkg_add. Just for that we have no choices but rebuilding everything that depends on B This can now be easily fixed because pkg_install is gone and we do not have to rely on compatiblity with it anymore, the problem is people willing to work on that (flexible dependencies and smart dependencies) have been mostly killed by the nightmare this compatibility has introduced into pkg. Lots of scripts still rely on the pkg_add behaviour and until all of them are killed I'm afraid we won't be able to prevent those massive rebuilds. That is if you are doing the things correctly. Now there is an alternative. Introduce a new repository format for file:// kind of url (like Zypper) which will not need all the metadata and be blazing fast to produce. Use pkg install instead of pkg add in ports and then we can reduce the massive rebuilds to only rebuild things that really requires a library and only a library being removed/upgraded. Any volunteers? regards, Bapt pgpLkP2eHxgtm.pgp Description: PGP signature
Re: Opera, still functional, 'one cannot make new configs' etc since v9 v10
I installed on FreeBSD 9.3 adm64 p5, with gtk2 off. KDE4 Plasma X server. Radeon xorg driver (ATI 7750 card). Got an error about missing libfreetype.so.9, but the browser seemed to work fine. ___ 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: poudriere: reduce the number of rebuilt packages?
Matthew Seaman matt...@freebsd.org writes: poudriere only knows that the dependency changed. In effect, to find out if the package of interest would be changed because of that, it has no other recourse than to build the package. Now, if you can come up with some heuristics whereby you can examine the changes to a port and determine that they will not cause significant downstream changes, and do that reliably and faster than just rebuilding the package, then I'm sure the poudriere developers would be eager to incorporate them. Failing that, poudriere re-building everything that might be affected is the sensible choice. If I know that only the actually changed ports need to be rebuilt, I go into my jail but instead of running poudriere, I use portmaster -g. Unfortunately, it's really easy to be wrong about knowing that. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ net/py-s3cmd| 1.5.0-rc1 | 1.5.0 +-+ www/trac| 1.0.1 | 1.1.3 +-+ x11-clocks/wmclock | 1.0.14 | 1.0.15 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
getpatch scripit rewroted in plain shell
Hi ports :) For a long time, I was missing some features in the exising getpatch script ( svn repo Tools/scripts/getpatch) and since I'm not a py fan boy, I rewrote the tool in plain shell. This is its storry The new features are : - use the bug id as a directory to store the attachements inside (can be turned off) - decide if you want or not obsolete patches (by default is no) - an env variable to define where attachements are stored (by default ./) - be verbose - only uses tools from base example : rodrigo@scotty % printenv GETPATCH_DIR /home/rodrigo/patches/ rodrigo@scotty % getpatch 191840 Bug ID: 191840 + att-144615: pidgin-gnome-keyring.tar.gz is obsolete, skip + att-144641: pidgin-gnome-keyring.tar.gz download success + att-144642: pidgin-gnome-keyring-1.20_1.txz download success Patches stored in /usr/home/rodrigo/patches/191840 The code is here : http://files.bebik.net/code/getpatch Suggestions and comments are wellcomed Regards, - rodrigo PS: There are room for improvements, I know. Bugzilla request can be reduced to a single one but this leads to xml and b64 management in shell, and it sounds a little bit insane to me... ___ 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
I'm only going to answer that part, the rest of the thread being, I feel, mostly FUD. +--On 10 janvier 2015 21:25:11 -0600 The BSD Dreamer beas...@tardisi.com wrote: | Count the | PORTREVISIONs to bind before 9.9.4 and after. Plus look at all the other | annoying changes in those PORTREVISIONs without that things have been | working fine for the rest of us before. Yes, let's say there are two kinds of maintainers, those who keep the bugs they find in the port until there is a new release to an absolute minimum so that people are not scared of the number of changes, and there are those, like me, that would rather have a dozen updates between releases, each addressing a bug when it arises. The BIND ports were in such a miserable way, with kludges everywhere, when I took over that it took me some time to get them right. -- Mathieu Arnold ___ 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 01/12/15 11:46, Chris H wrote: My main complaint with pkg is the persistent misunderstanding that binary packages are a direct replacement for ports. http://www.wonkity.com/~wblock/docs/html/pkg.html I'd be inclined to agree here. There are some ports that almost demand a local version - apr (Apache Portability Library) being one of them. Currently, I am locking 'apr' so that pkg upgrade does not clobber apr, and this has worked so far. Just an observation. -- Patrick Powell Astart Technologies papow...@astart.com1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting 858-874-6543 FAX 858-751-2435 Web: www.astart.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: getpatch scripit rewroted in plain shell
On Tue, 13 Jan 2015 13:49:31 + Rodrigo Osorio rodr...@bebik.net wrote Hi ports :) For a long time, I was missing some features in the exising getpatch script ( svn repo Tools/scripts/getpatch) and since I'm not a py fan boy, I rewrote the tool in plain shell. This is its storry The new features are : - use the bug id as a directory to store the attachements inside (can be turned off) - decide if you want or not obsolete patches (by default is no) - an env variable to define where attachements are stored (by default ./) - be verbose - only uses tools from base example : rodrigo@scotty % printenv GETPATCH_DIR /home/rodrigo/patches/ rodrigo@scotty % getpatch 191840 Bug ID: 191840 + att-144615: pidgin-gnome-keyring.tar.gz is obsolete, skip + att-144641: pidgin-gnome-keyring.tar.gz download success + att-144642: pidgin-gnome-keyring-1.20_1.txz download success Patches stored in /usr/home/rodrigo/patches/191840 The code is here : http://files.bebik.net/code/getpatch Suggestions and comments are wellcomed Looks good. Your native language appears to be français. :) I would only offer grammatical changes: s/a dedicate/the dedicated/g s/dedicate/dedicated/g # I try to avoid contractions because some shells trip on the apostrophe. s/Can\'t/Unable to/g s/catched/caught/g Bon travail! --Chris Regards, - rodrigo PS: There are room for improvements, I know. Bugzilla request can be reduced to a single one but this leads to xml and b64 management in shell, and it sounds a little bit insane to me... ___ 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: BIND REPLACE_BASE option
On Tue, 13 Jan 2015 16:12:32 +0100 Mathieu Arnold m...@freebsd.org wrote I'm only going to answer that part, the rest of the thread being, I feel, mostly FUD. Apologies for any contribution(s) I might have made in that area. +--On 10 janvier 2015 21:25:11 -0600 The BSD Dreamer beas...@tardisi.com wrote: | Count the | PORTREVISIONs to bind before 9.9.4 and after. Plus look at all the other | annoying changes in those PORTREVISIONs without that things have been | working fine for the rest of us before. Yes, let's say there are two kinds of maintainers, those who keep the bugs they find in the port until there is a new release to an absolute minimum so that people are not scared of the number of changes, and there are those, like me, that would rather have a dozen updates between releases, each addressing a bug when it arises. The BIND ports were in such a miserable way, with kludges everywhere, when I took over that it took me some time to get them right. I saw that mess -- more than once. Thank you for taking that on! --Chris -- Mathieu Arnold ___ 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: getpatch scripit rewroted in plain shell
On 13/01/15 07:11 -0800, Chris H wrote: On Tue, 13 Jan 2015 13:49:31 + Rodrigo Osorio rodr...@bebik.net wrote Hi ports :) For a long time, I was missing some features in the exising getpatch script ( svn repo Tools/scripts/getpatch) and since I'm not a py fan boy, I rewrote the tool in plain shell. This is its storry The new features are : - use the bug id as a directory to store the attachements inside (can be turned off) - decide if you want or not obsolete patches (by default is no) - an env variable to define where attachements are stored (by default ./) - be verbose - only uses tools from base example : rodrigo@scotty % printenv GETPATCH_DIR /home/rodrigo/patches/ rodrigo@scotty % getpatch 191840 Bug ID: 191840 + att-144615: pidgin-gnome-keyring.tar.gz is obsolete, skip + att-144641: pidgin-gnome-keyring.tar.gz download success + att-144642: pidgin-gnome-keyring-1.20_1.txz download success Patches stored in /usr/home/rodrigo/patches/191840 The code is here : http://files.bebik.net/code/getpatch Suggestions and comments are wellcomed Looks good. Your native language appears to be français. :) I would only offer grammatical changes: s/a dedicate/the dedicated/g s/dedicate/dedicated/g # I try to avoid contractions because some shells trip on the apostrophe. s/Can\'t/Unable to/g s/catched/caught/g Bon travail! --Chris Regards, - rodrigo PS: There are room for improvements, I know. Bugzilla request can be reduced to a single one but this leads to xml and b64 management in shell, and it sounds a little bit insane to me... ___ 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 Chris, Thanks for your feedback, I really appreciate your contribution. The file now includes the suggested changes. - rodrigo ___ 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 01/13/15 15:24, Patrick Powell wrote: On 01/12/15 11:46, Chris H wrote: My main complaint with pkg is the persistent misunderstanding that binary packages are a direct replacement for ports. http://www.wonkity.com/~wblock/docs/html/pkg.html I'd be inclined to agree here. The aim with pkg(8) in this regard was to make it possible to maintain a machine using only binary packages. Something that it has succeeded at, given the proviso that you have access to a repo with all the customizations you need available. If the default options don't cut it for you, in order to use only binary packages that means you need to run your own poudriere setup -- which is well worth it if you're managing several machines / jails etc. You don't need a ports tree on every single machine, and the length of your intervention on a production server is pretty much as long as 'pkg upgrade' takes to run, which is much quicker and less intrusive than running builds locally. However, while pkg(8) now has the right mechanics to maintain a machine with binaries only, the ports tree is still (despite all the work that has been going into it recently) not yet set up to support doing that very effectively. In essence, we'd need to be building several different 'flavours' for certain packages, along with various other enhancements like sub-packages and PROVIDES/REQUIRES style dependencies. Note that *none* of this is going to impede building stuff straight out of ports in the time honoured fashion. That simply is not on the pkg(8) agenda. There are some ports that almost demand a local version - apr (Apache Portability Library) being one of them. Currently, I am locking 'apr' so that pkg upgrade does not clobber apr, and this has worked so far. Just an observation. Yes, absolutely. The configurability with the ports tree is one of it's major benefits, and yet also a significant hindrance in many circumstances. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: BIND REPLACE_BASE option
Hi! customizations you need available. If the default options don't cut it for you, in order to use only binary packages that means you need to run your own poudriere setup -- which is well worth it if you're managing several machines / jails etc. poudriere allows you to manage several seperate pkg trees with different options, so you can: - build a default tree (and pkg repo), provide it to all generic hosts - build a seperate tree (and pkg repo) with modified options, and provide it to the special hosts It helps to keep the poudriere build tree on fast flash/SSD drives 8-} This all works and is very, very good! Thanks for the work! -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ 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 Tue, 13 Jan 2015 16:55:53 +0100 Kurt Jaeger li...@opsec.eu wrote Hi! customizations you need available. If the default options don't cut it for you, in order to use only binary packages that means you need to run your own poudriere setup -- which is well worth it if you're managing several machines / jails etc. poudriere allows you to manage several seperate pkg trees with different options, so you can: - build a default tree (and pkg repo), provide it to all generic hosts - build a seperate tree (and pkg repo) with modified options, and provide it to the special hosts I use a similar, but somewhat different strategy. Which works nice if you have any spare hardware available. I simply use a fresh install of whatever RELEASE/RELENG I'm chasing. * create a dump(8) to external storage * build/install (custom) world/kernel * (batch) build install clean ports with desired options * dump to external storage * restore to target host/machine and as Kurt mentioned; flash/SSD media *is* the way to go! :) I ended up going this route because I found the builds ran quicker, and it all ended up being a bit tidier. Also makes it trivial to rollback to any chosen revision. --Chris It helps to keep the poudriere build tree on fast flash/SSD drives 8-} This all works and is very, very good! Thanks for the work! -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ 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: BIND REPLACE_BASE option
Mathieu Arnold wrote: I'm only going to answer that part, the rest of the thread being, I feel, mostly FUD. ... The BIND ports were in such a miserable way, with kludges everywhere, when I took over that it took me some time to get them right. I wish people wouldn't make statements like this. The thread has been informative in many ways and clearly not FUD. I also wish people would not insult previous base and port maintainers by labelling their work buggy or kludgy. All code has bugs. Even having a REPLACE_BASE that only prints REPLACE_BASE is no longer supported can be considered a bug. Having two identically named binaries on a system that differ only by path and version can also be considered a kludge (not to mention a security issue). While I'm not personally impacted by the bind port's deprecation of REPLACE_BASE clearly others are. As Doug pointed out this option has been around for well over a decade and like other ports with a REPLACE_BASE option has saved FreeBSD admins a lot of work in cross-platform environments. One question while we're on the topic of deprecations, has 'make pkg || make package' been deprecated in favor of poudriere? Roger ___ 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: games/wesnoth: How to cope with invalid DSO for symbol `_ZN5boost6system15system_categoryEv'
On 10.01.2015 09:05, Torsten Zühlsdorff wrote:
What is the output of the following command on both computers (the one
it works on and the one it doesn't)?
# pkg info boost-libs
At the moment i just have access to the *not* working one. I try to find
time at the weekend to look up the information at the other one.
Because i don't know if you can already see something, i post the
requested info for the *not* working one directly:
=== start ===
[output]
=== end ===
As you can see they just differ in Architecture.
After some searching and trying i can confirm, that adding this line fix
the problem:
LDFLAGS+= -L${LOCALBASE}/lib -lboost_system
I don't understand why, but that's a huge step forward :)
Next step: cleaning the pkg-plist :)
Greetings,
Torsten
___
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/bbcp: Anyone interesting in helping upgrade this port?
On Tue, 13 Jan 2015 10:43:15 -0800 Freddie Cash fjwc...@gmail.com wrote On Tue, Jan 13, 2015 at 10:17 AM, Chris H bsd-li...@bsdforge.com wrote: On Tue, 13 Jan 2015 10:08:05 -0800 Freddie Cash fjwc...@gmail.com wrote Good morning, With the requirement for the NONE cipher in OpenSSH requiring a custom compile of the world or a custom compile of the openssh-portable port (all my production servers are binary-package-only now), I've started using bbcp instead of zfs send over SSH. And looking at using bbcp instead of rsync over SSH for another system (transfer speed is more important than encrypting the data as the transfer is done over a very local LAN link). The bbcp port is version 20120520; the latest version available is 20140902. There have been several new features added over the past 2 years that make it (at least on paper) a decent rsync replacement for our uses. Is there anyone interested in bringing this port up-to-date. I had a quick look, but it requires some C hacking that's beyond my skills. :( I've only tried compiling it with clang, which gives lots of errors. Haven't tried with gcc, though. I just had a look. Looks interesting. I can't foresee any issue moving it ahead. But before I step up, and say I'll take it. Have you contacted the maintainer? I don't want to step on any toes. :) Well, now I feel sheepish. I was looking at the freshports.org page for it and just saw portmgr-related commits to the port and assumed it was maintained by freebsd-ports (aka not maintained). I completely missed the little Maintainer line at the top. :( I've CC'd the port Maintainer to bring them into the loop. [Being a past port maintainer, I really should know better.] LOL No worries. :) I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) All the best! -- Freddie Cash fjwc...@gmail.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 --Chris --- ___ 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: games/wesnoth: How to cope with invalid DSO for symbol `_ZN5boost6system15system_categoryEv'
On 1/9/2015 5:18 AM, Torsten Zuehlsdorff wrote: [ 3%] mo-update [wesnoth-dw-ar]: Creating mo file. /usr/bin/ld: g: invalid DSO for symbol `_ZN5boost6system15system_categoryEv' definition /usr/local/lib/libboost_system.so.1.55.0: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) --- cutter --- Usually this means -lboost_system is missing from the linker line. Recent binutils in recent FreeBSD head has been patched to be more clear about it. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
sysutils/logstash leaves me without working file input
Hi Ports,
I installed the latest sysutils/logstash port in a fresh 10.1 jail and tried
the following:
# /usr/local/logstash/bin/logstash -f /home/user/src/conf/logstash.conf
which gave the following output:
Using milestone 2 input plugin 'file'. This plugin should be stable, but if you
see strange behavior, please let us know! For more information on plugin
milestones, see http://logstash.net/docs/1.4.2/plugin-milestones {:level=:warn}
NotImplementedError: stat.st_dev unsupported or native support failed to load
dev_major at org/jruby/RubyFileStat.java:190
_discover_file at
/usr/local/logstash/vendor/bundle/jruby/1.9/gems/filewatch-0.5.1/lib/filewatch/watch.rb:140
each at org/jruby/RubyArray.java:1613
_discover_file at
/usr/local/logstash/vendor/bundle/jruby/1.9/gems/filewatch-0.5.1/lib/filewatch/watch.rb:122
watch at
/usr/local/logstash/vendor/bundle/jruby/1.9/gems/filewatch-0.5.1/lib/filewatch/watch.rb:34
tail at
/usr/local/logstash/vendor/bundle/jruby/1.9/gems/filewatch-0.5.1/lib/filewatch/tail.rb:58
run at /usr/local/logstash/lib/logstash/inputs/file.rb:130
each at org/jruby/RubyArray.java:1613
run at /usr/local/logstash/lib/logstash/inputs/file.rb:130
inputworker at /usr/local/logstash/lib/logstash/pipeline.rb:163
start_input at /usr/local/logstash/lib/logstash/pipeline.rb:157
So it seems, that the file {} input is not working, which seems to be related
to this Bug: https://logstash.jira.com/browse/LOGSTASH-1819.
However, unlike mentioned in the Bugreport, the Port is not working for me.
In case its of interest, the logstash.conf looks like the following:
input {
file {
path = /tmp/test.log
start_position = beginning
}
}
filter {
grok {
match = { message = %{COMBINEDAPACHELOG} }
}
date {
match = [ timestamp , dd/MMM/:HH:mm:ss Z ]
}
}
output {
elasticsearch {
host = localhost
}
stdout { codec = rubydebug }
}
Am I missing something? Is something wrong with the port? In case, there is: Is
there something I can help with to get that resolved?
Thanks,
Filias
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: sysutils/bbcp: Anyone interesting in helping upgrade this port?
Kurt Jaeger wrote at 20:29 +0100 on Jan 13, 2015: I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I don't think he will (as can be seen from PR 192405). Provide a PR with the patch and I'll commit it after testing the build. I'll update it if no one else gets to it this week or review a PR. Willing to hand it over if someone wants it. ___ 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: Build Failure: webkit-gtk2
## Per olof Ljungmark (p...@intersonic.se): CXXLDlibWTF.la CXXLDPrograms/LLIntOffsetsExtractor /usr/bin/ld:./.libs/libWTF.a: file format not recognized; treating as linker script /usr/bin/ld:./.libs/libWTF.a:1: syntax error c++: error: linker command failed with exit code 1 (use -v to see invocation) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196296 That, and the related/duplicate 196333 and 195500 (webkit-gtk3). Due to a maintenance issue, changes to bugs between 2015-01-07 and 2015-01-10 were lost. Please resubmit any updates as appropriate. We apologize for the inconvenience. Great for those who do not check bugzilla on a daily basis :) Anyway, to reliably build webkit-gtk you must enable BOTH WEBGL and WEBAUDIO, otherwise the build will fail. Those options are gone with the update to webkit-gtk 2.4.8 (in both the -gtk2 and the -gtk3 port). There had been two problems, one related to GNU ar and the other one when building with non-default OPTIONS. The latter one has been resolved in r376609, the former one has not been fixed yet - despite rather distinct error messages, the problems have been mixed up in the PRs. Is any gnome@ committer around to commit the rest of the fixes? Regards, Christoph -- Spare Space ___ 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: Build Failure: webkit-gtk2
On 13-1-2015 22:13, Christoph Moench-Tegeder wrote: ## Per olof Ljungmark (p...@intersonic.se): CXXLDlibWTF.la CXXLDPrograms/LLIntOffsetsExtractor /usr/bin/ld:./.libs/libWTF.a: file format not recognized; treating as linker script /usr/bin/ld:./.libs/libWTF.a:1: syntax error c++: error: linker command failed with exit code 1 (use -v to see invocation) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196296 That, and the related/duplicate 196333 and 195500 (webkit-gtk3). Due to a maintenance issue, changes to bugs between 2015-01-07 and 2015-01-10 were lost. Please resubmit any updates as appropriate. We apologize for the inconvenience. Great for those who do not check bugzilla on a daily basis :) Anyway, to reliably build webkit-gtk you must enable BOTH WEBGL and WEBAUDIO, otherwise the build will fail. Those options are gone with the update to webkit-gtk 2.4.8 (in both the -gtk2 and the -gtk3 port). There had been two problems, one related to GNU ar and the other one when building with non-default OPTIONS. The latter one has been resolved in r376609, the former one has not been fixed yet - despite rather distinct error messages, the problems have been mixed up in the PRs. Is any gnome@ committer around to commit the rest of the fixes? Regards, Christoph That would be me. Hardcoding AR=/usr/bin/ar isn't a fix I like. Like Kurt mentioned earlier: The webkit-gtk2 build fails if the ports 'ar' is found before the system 'ar'. Check $PATH and put /usr/bin before /usr/local/bin. - What I would like to know is why people are changing PATH? -Koop ___ 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 13 janvier 2015 08:33:13 -0800 Roger Marquis marq...@roble.com wrote: | Even having a REPLACE_BASE that | only prints REPLACE_BASE is no longer supported can be considered a | bug. Would you rather the port installing BIND in /usr/local without telling you anything, silently breaking your installation completely ? I thought people would rather have the port telling them the option is no longer supported so that they can fix their installation before it blows up. But maybe it's just me. -- Mathieu Arnold ___ 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: Build Failure: webkit-gtk2
Hi! What I would like to know is why people are changing PATH? Because we can (most of the time), and sometimes it helps. And sometimes we detect broken things 8-} If a port needs a specific version of ar, can't that be made part of the build ? -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ 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: Build Failure: webkit-gtk2
## Koop Mast (k...@rainbow-runner.nl): Hardcoding AR=/usr/bin/ar isn't a fix I like. Well, webkit-gtk (and www/chromium earlier, we have the same problem/fix there) use base system's ld (that's because it's called by your compiler of-the-day) but some ar (which is found by configure). AFAIK there's no real official way to force use of one toolchain (instead of mix and match). What I would like to know is why people are changing PATH? Because sometimes we like to use the things we installed in LOCALBASE :) Regards, Christoph -- Spare Space ___ 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/bbcp: Anyone interesting in helping upgrade this port?
With the requirement for the NONE cipher in OpenSSH requiring a custom compile of the world or a custom compile of the openssh-portable port Note that there are 2 open PRs on freebsd base to turn the NONE cipher option on by default in the build process of ssh in freebsd base (as was agreed in the freebsd current mailing list): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163127 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163095 -- -- From: Benjamin Woods woods...@gmail.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: BIND REPLACE_BASE option
Mathieu Arnold wrote: Would you rather the port installing BIND in /usr/local without telling you anything, silently breaking your installation completely ? Certainly not but it's unprofessional to present the end-user with a dialog option that can be selected only to subsequently inform them that the option is deprecated. It might take a little programming but the error message printed when one port would overwrite files installed by another would, IMO, be better i.e., recommending removal of the conflict before installation. Roger ___ 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
