Re: Berkeley DB cleanup has apparently broken ports where no db is currently installed

2013-12-28 Thread Kevin Oberman 
On Thu, Dec 26, 2013 at 12:56 AM, Doug Barton  wrote:

> On 12/26/2013 12:41 AM, Matthias Andree wrote:
>
>> I disagree on the assessments of efforts here. I checked the docs,
>> and the actual .db files are supposed to be compatible,
>>
>
> Sure, they are, to some extent, SUPPOSED to be compatible. Experience
> tells us that is not the case.
>
>
>  excepting the
>> corner cases mentioned in the wiki. The manual effort only exists for
>> ports using BDB in transactional mode, while most ports just use it
>> as a key-value data vault.
>>
>
> So you're volunteering to walk every user whose stuff gets broken through
> the repair?
>
>
>  Ttbomk, deprecated does not cause build failures, and even if so,
>> WITH_BDB_VER=5 would fix that.
>>
>
> portmaster treats DEPRECATED as a fatal error. I did neglect to point that
> out in my previous post however.
>
>  Finally, I would like to see technical or other_compelling_  reasons
>>
>> why we would need 48 in the tree in the future.
>>
>
> Well shouldn't that argument go the other way around? Shouldn't the people
> proposing the purge be the ones to provide _compelling_ reasons to do the
> purge?
>
>
> Doug
>

I updated from 9-Stable to 10.0-RC3 dy before yesterday. I had one odd
error during the upgrade, but  managed to complete the upgrade. Then I
re-built all ports. I had a few issues, all resolved except one that i have
opened a PR for, but I did have a very annoying time with Berkeley DB.

I had deleted all ports, so I assumed that port requiring Berkeley DB would
use db5 or db6. But, as Doug noted, no such luck. As Doug pointed out, this
is because some ports require db4x. Specifically,
databases/evolution-data-server required db41. No option for any newer
version. apr1 required db42+, but that just pulls in db4* forts, so no db5
gets installed, even though the port clearly stats that it works with 5. So
4.2+ really means any db4. version.

There is no reason that ports using "USE_BDB=4.\+ could not have been found
(by a simple grep) and been "fixed" to use db5 (assuming that they really
do work with db5), but they were not. Or the Mk files could have caused the
cases where db4.\+ were called for that this could not have installed db5
or even db6 rather than insist on db4. (And, quite oddly, the LOWEST db4
version that allowed was the one installed when no matching db was
installed.

Rather than mess around with fixing multiple Makefiles while my system was
unable to do much of anything, I just removed the DEPRECATED lines form
db41, db42, and db43. I'll need to go clean them all up, now. And some
don't even make it clear that they will run with db5.  And I still have
seen no reason that the db4 ports really needed removal. They still work
fine and are widely used. Deprecation was just asking for trouble. (Don't
forget that a "DEPRECATED" statement in a port Makefile is fatal.)

I will also mention that the man page for portmaster REALLY needs to be
updated for pkgng. This wasted just a bit more of my time. Due to the iconv
move to base, the "quick and dirty" rebuild option of "portmaster -aD"
fails miserably. I suspect portupgrade would have a similar problem, but I
have not used it in a couple of years, so I can't be sure.

On the whole, I have to call this one a really botched change that should
be rolled back until it can be implemented to work properly, at least for a
clean install of all ports.
-- 
R. Kevin Oberman, Network Engineer
E-mail: rkober...@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: ntp-devel-4.2.7p364_2 coredumps

2013-12-28 Thread Cy Schubert 
In message <5ad6315c-f8d5-477c-8e30-cab70221e...@lassitu.de>, Stefan Bethke 
wri
tes:
> 
> --Apple-Mail=_C732F0FB-B1AF-463B-AAFC-A6C2FA82A3B2
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain;
>   charset=us-ascii
> 
> Am 28.12.2013 um 06:13 schrieb Cy Schubert :
> 
> > In message , Stefan =
> Bethke=20
> > wri
> > tes:
> >>=20
> >> --Apple-Mail=3D_6EEA81A7-5FCB-41CB-A6F5-4CBEDAB3BBAE
> >> Content-Transfer-Encoding: quoted-printable
> >> Content-Type: text/plain;
> >>charset=3Dus-ascii
> >>=20
> >> On both 9-stable and 10-stable
> >>=20
> >> Dec 26 13:02:04 lokschuppen ntpd[5270]: ntpd 4.2.7p364@1.2483-o Thu =
> Dec =3D
> >> 26 12:55:22 UTC 2013 (1): Starting
> >> Dec 26 13:02:04 lokschuppen ntpd[5270]: Command line: =3D
> >> /usr/local/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -f =3D
> >> /var/db/ntpd.drift
> >> Dec 26 13:02:05 lokschuppen kernel: pid 5271 (ntpd), uid 0: exited on =
> =3D
> >> signal 11 (core dumped)
> >=20
> > p404 has just been committed. Let's see if it makes a difference.
> >=20
> > Let me know what uname -a shows and any options/optional modules =
> compiled=20
> > or loaded.
> 
> That seems to have done the trick, thank you!

Good stuff! You're welcome.
> 
> The problem occurred on both
> FreeBSD diesel.lassitu.de 10.0-PRERELEASE FreeBSD 10.0-PRERELEASE #5 =
> r259696: Sun Dec 22 00:13:23 CET 2013 =
> r...@diesel.lassitu.de:/usr/obj/var/freebsd/10-stable/sys/DIESEL  amd64
> and
> FreeBSD lokschuppen.zs64.net 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #2 =
> r255602: Sun Sep 15 21:25:57 UTC 2013 =
> r...@lokschuppen.zs64.net:/usr/obj/freebsd/checkout/src/sys/EISENBOOT  =
> amd64

I bet it was in the port.

You know, -devel ports are just that, development code. Everyone should be 
aware that -devel ports are not totally prod ready.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org


> with defaults for the port:
> # make showconfig
> =3D=3D=3D> The following configuration options are available for =
> ntp-devel-4.2.7p404:
>  ACTS=3Doff: Enable ACTS modem service
>  ARBITER=3Doff: Enable Arbiter 1088A/B GPS receiver
>  ARCRON_MSF=3Doff: Enable Arcron MSF receiver
>  AS2201=3Doff: Enable Austron 2200A/2201A GPS receiver
>  ATOM=3Don: Enable ATOM PPS interface
>  AUDIO_CHU=3Doff: Enable CHU audio/decoder
>  BANCOMM=3Doff: Enable Datum/Bancomm bc635/VME interface
>  CHRONOLOG=3Doff: Enable Chrono-log K-series WWVB receiver
>  CHU=3Doff: Enable CHU modem/decoder
>  COMPUTIME=3Doff: Enable Diem Computime Radio Clock
>  DATUM=3Doff: Enable Datum Programmable Time System
>  DCF7000=3Doff: Enable ELV/DCF7000 clock
>  DUMBCLOCK=3Doff: Enable Dumb generic hh:mm:ss local clock
>  FG=3Doff: Enable Forum Graphic GPS
>  GPSVME=3Doff: Enable TrueTime GPS receiver/VME interface
>  HEATH=3Doff: Enable Heath GC-1000 WWV/WWVH receiver
>  HOPF6021=3Doff: Enable HOPF 6021 clock
>  HOPFPCI=3Doff: Enable hopf 6039 PCI board
>  HOPFSERIAL=3Doff: Enable hopf serial clock device
>  HPGPS=3Doff: Enable HP 58503A GPS receiver
>  IPV6=3Don: IPv6 protocol support
>  IRIG=3Doff: Enable IRIG audio decoder
>  JJY=3Doff: Enable JJY receiver
>  JUPITER=3Doff: Enable Rockwell Jupiter GPS receiver
>  LEITCH=3Doff: Enable Leitch CSD 5300 Master Clock
>  LOCAL_CLOCK=3Doff: Enable local clock reference
>  MEINBERG=3Doff: Enable Meinberg clocks
>  MX4200=3Doff: Enable Magnavox MX4200 GPS receiver
>  NEOCLOCK4X=3Doff: Enable NeoClock4X DCF77 / TDF receiver
>  NMEA=3Don: Enable NMEA GPS receiver
>  NTPSNMPD=3Doff: Build and install ntpsnmpd
>  NTP_SIGND=3Don: Enable signed NTP
>  ONCORE=3Doff: Enable Motorola VP/UT Oncore GPS receiver
>  PALISADE=3Doff: Enable Palisade clock
>  PCF=3Doff: Enable Conrad parallel port radio clock
>  PST=3Doff: Enable PST/Traconex 1020 WWV/WWVH receiver
>  RAWDCF=3Doff: Enable DCF77 raw time code
>  RCC8000=3Doff: Enable RCC 8000 clock
>  RIPENCC=3Doff: Enable RIPENCC specific Trimble driver
>  SCHMID=3Doff: Enable Schmid DCF77 clock
>  SEL240X=3Doff: Enable SEL 240X clocks
>  SHM=3Doff: Enable SHM clock attached thru shared memory
>  SPECTRACOM=3Doff: Enable Spectracom 8170/Netclock/2 WWVB
>  SSL=3Don: SSL protocol support
>  TRIMTAIP=3Doff: Enable Trimble GPS receiver/TAIP protocol
>  TRIMTSIP=3Doff: Enable Trimble GPS receiver/TSIP protocol
>  TRUETIME=3Doff: Enable Kinemetrics/TrueTime receivers
>  ULINK=3Doff: Enable Ultralink WWVB receiver
>  VARITEXT=3Doff: Enable VARITEXT clock
>  WHARTON=3Doff: Enable WHARTON 400A Series clock
>  WWV=3Doff: Enable WWV Audio receiver
>  ZYFER=3Doff: Enable Zyfer GPStarplus receiver
> =3D=3D=3D> Use 'make config' to modify these settings
> --=20
> Stefan BethkeFon +49 151 14070811
> 
> 
> 
> 
> 
> --Apple-Mail=_C732F0FB-B1AF-463B-AAFC-A6C2FA82A3B2
> Content-Transfer-Encoding: 7bit
> Co

Re: dns/bind* ports overwriting conf files

2013-12-28 Thread Doug Barton 

On 12/28/2013 02:57 AM, Mathieu Arnold wrote:

+--On 27 décembre 2013 17:18:43 -0800 Doug Barton 
wrote:
| What I proposed as part of this work years ago was to create something
| like a bind-config package that would (optionally) install the same
| default files and configuration for the port that are still in the base
| for [89].x. That way users who just wanted the old default local resolver
| could get that behavior easily, and users with other needs would not have
| to have it. I still think that's the easiest and least painful way to
| manage the transition, and would encourage Erwin to consider it. (For
| extra credit, a different but similar sort of port should be created to
| enable DNSSEC validation, and should include the root zone trust anchor,
| and a description of how the user can validate it for themselves.)

That's some interesting ideas, yes, the maintainer of bind will certainly
keep them in mind, whoever he is in the future. Having the possibility of
get sub packages and flavors in a few months will really help in that way.

| In any case even a _plan_ to overwrite conf files blindly is a bad idea.
| So much the better to fix it now before it actually bites any users.

Yes, it was, and it was fixed as soon as Erwin learnt about it. What I was
saying is that it only appears on freebsd where bind was absent from the
base, which, at that time was 10.0-BETAsomething or 11-CURRENT. I know it
was a *big* bug, but the impact was small because the os versions were not
releases.


Thank you for considering my thoughts on the matter.

Doug

___
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 vertical split

2013-12-28 Thread Zsolt Udvari 
Sorry, if I was equivocal:
* I'm using tmux and I can split vertically (and horizontally, of course :) )
* I'm not using screen but I've installed for a probe and I think
isn't possible to split vertically (without patching)

Cheers,
  Zsolt


2013/12/28 Florent Peterschmitt :
> Le 28/12/2013 17:07, Zsolt Udvari a écrit :
>> 2013/12/28 James Griffin :
>>> yeah, it's in the docs I found online, although not in the man page on
>>> FreeBSD.
>> Ahh. I don't find it in FreeBSD's manpage.
>> I'm using tmux but installed now screen and as I see there's not vertical 
>> split.
>
> What version of FreeBSD and Screen/Tmux are you using? I can do a
> vertical split with Tmux 1.7/1.8 (dont know for screen) and FreeBSD 9/10
>
>
> --
> Florent Peterschmitt   | Please:
> flor...@peterschmitt.fr|  * Avoid HTML/RTF in E-mail.
> +33 (0)6 64 33 97 92   |  * Send PDF for documents.
> http://florent.peterschmitt.fr |  * Trim your quotations. Really.
> Proudly powered by Open Source | Thank you :)
>
___
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: bsd.port.mk FETCH_ARGS defaults, why "-A" ?

2013-12-28 Thread John Marino 
On 12/28/2013 02:27, Baptiste Daroussin wrote:
> On Sat, Dec 28, 2013 at 02:05:31AM +0100, Michael Gmelin wrote:
>> On Sat, 28 Dec 2013 01:56:22 +0100
>> Baptiste Daroussin  wrote:
>>
>>> On Sat, Dec 28, 2013 at 01:52:45AM +0100, John Marino wrote:
 On 12/28/2013 01:49, Dimitry Andric wrote:
> On 28 Dec 2013, at 01:12, John Marino 
> wrote:
>> For months I've been getting a lot of fetch failures in ports
>> that I couldn't reproduce outside of them.  It appears it is
>> caused by the default "-A" passed to fetch.
>>
>> For example, /usr/ports/emulators/javatari will fail with "make
>> fetch" but it will succeed with with "make fetch FETCH_ARGS=-Fpr"
>>
>> I'd like to understand why "-A" is the default.  Clearly many
>> distfiles could be retrieved that aren't, so I'd like to know
>> what -A is saving us from, and why that would be worse than the
>> current situation?
>
> Crappy download sites that redirect you to ad pages, malware
> domains, or worse?
>

 And?
 The checksum won't match, and the next site in the MASTER_SITES list
 will be checked, right?  What is the downside of this redirect?
 Keep in mind that the site was once "approved" by the port
 maintainer, it's not some random URL stuck in a wiki.
>>>
>>> That's to avoid infinite loop on redirection
>>>
>>> bapt
>>
>> libfetch allows a maximum um five redirects and the -A flag is
>> implemented in terms of limiting this to one:
>>
>> http.c:
>> ...
>> /* Maximum number of redirects to follow */
>> #define MAX_REDIRECT 5
>> ...
>>   /* if the A flag is set, we only get one try */
>>   n = noredirect ? 1 : MAX_REDIRECT;
>>   i = 0;
>> ...
>>
> 
> Great so that s not an argument anymore, it was the argument I was told 2 
> years
> ago when I proposed to remove the -A
> 

Does that mean that "-A" option will be removed in the near future?  As
Doug indicated, there doesn't seem to be any current reason to have it
and sufficient reason not to have it.

John
___
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] recursive dependency registration is gone for pkgng users

2013-12-28 Thread Baptiste Daroussin 
On Sat, Dec 28, 2013 at 04:45:41PM +, Matthew Seaman wrote:
> On 28/12/2013 16:31, Yasuhiro KIMURA wrote:
> > From: Baptiste Daroussin 
> > Subject: [HEADSUP] recursive dependency registration is gone for pkgng users
> > Date: Sat, 28 Dec 2013 15:52:50 +0100
> > 
> >> as a side effect,
> >> tinderbox and poudriere users do need to rebuild all their packages from
> >> scratch.
> > 
> > Does this mean rebuilding is necessary only if either tinderbox or
> > poudriere are used, or all packages have to be rebuilt anyway if pkgng
> > is used?
> 
> If you are running your own pkg repo, then you should rebuild all the
> packages you supply from it.
> 
> You shouldn't need to rebuild / reinstall all of the packages already
> installed on your system -- they will continue to work just fine.  As
> time goes on, and you naturally upgrade installed packages as part of
> normal system maintenance, you may notice the dependency lists changing,
> but that's about all.
> 
> The point of this change is to help binary package management choosing
> the right set of packages from available repositories as it works; if
> you're building everything locally via portmaster(8) or otherwise, then
> it's not going to have much effect on you.
> 
To be exact the only risk is that builders and only builders like tinderbox and
poudriere might have some strange build failures because of weird missing
dependencies due to old packages badly tracking dependencies, no problem when
using those packages

FYI pkg_install is still recursively tracking dependencies and won't be changed.

regards,
Bapt


pgpw4UimmhhAk.pgp
Description: PGP signature

Re: [HEADSUP] recursive dependency registration is gone for pkgng users

2013-12-28 Thread Matthew Seaman 
On 28/12/2013 16:31, Yasuhiro KIMURA wrote:
> From: Baptiste Daroussin 
> Subject: [HEADSUP] recursive dependency registration is gone for pkgng users
> Date: Sat, 28 Dec 2013 15:52:50 +0100
> 
>> as a side effect,
>> tinderbox and poudriere users do need to rebuild all their packages from
>> scratch.
> 
> Does this mean rebuilding is necessary only if either tinderbox or
> poudriere are used, or all packages have to be rebuilt anyway if pkgng
> is used?

If you are running your own pkg repo, then you should rebuild all the
packages you supply from it.

You shouldn't need to rebuild / reinstall all of the packages already
installed on your system -- they will continue to work just fine.  As
time goes on, and you naturally upgrade installed packages as part of
normal system maintenance, you may notice the dependency lists changing,
but that's about all.

The point of this change is to help binary package management choosing
the right set of packages from available repositories as it works; if
you're building everything locally via portmaster(8) or otherwise, then
it's not going to have much effect on you.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey




signature.asc
Description: OpenPGP digital signature

Re: Screen vertical split

2013-12-28 Thread Florent Peterschmitt 
Le 28/12/2013 17:07, Zsolt Udvari a écrit :
> 2013/12/28 James Griffin :
>> yeah, it's in the docs I found online, although not in the man page on
>> FreeBSD.
> Ahh. I don't find it in FreeBSD's manpage.
> I'm using tmux but installed now screen and as I see there's not vertical 
> split.

What version of FreeBSD and Screen/Tmux are you using? I can do a
vertical split with Tmux 1.7/1.8 (dont know for screen) and FreeBSD 9/10


-- 
Florent Peterschmitt   | Please:
flor...@peterschmitt.fr|  * Avoid HTML/RTF in E-mail.
+33 (0)6 64 33 97 92   |  * Send PDF for documents.
http://florent.peterschmitt.fr |  * Trim your quotations. Really.
Proudly powered by Open Source | Thank you :)



signature.asc
Description: OpenPGP digital signature

Re: [HEADSUP] recursive dependency registration is gone for pkgng users

2013-12-28 Thread Baptiste Daroussin 
On Sun, Dec 29, 2013 at 01:31:22AM +0900, Yasuhiro KIMURA wrote:
> From: Baptiste Daroussin 
> Subject: [HEADSUP] recursive dependency registration is gone for pkgng users
> Date: Sat, 28 Dec 2013 15:52:50 +0100
> 
> > as a side effect,
> > tinderbox and poudriere users do need to rebuild all their packages from
> > scratch.
> 
> Does this mean rebuilding is necessary only if either tinderbox or
> poudriere are used, or all packages have to be rebuilt anyway if pkgng
> is used?
> 
Only when building with tinderbox/poudriere, people bulding other ways are safe
and the packages will on the flow drop their useless dependencies

regards,
Bapt


pgpktFq5WSvzD.pgp
Description: PGP signature

Re: [HEADSUP] recursive dependency registration is gone for pkgng users

2013-12-28 Thread Yasuhiro KIMURA 
From: Baptiste Daroussin 
Subject: [HEADSUP] recursive dependency registration is gone for pkgng users
Date: Sat, 28 Dec 2013 15:52:50 +0100

> as a side effect,
> tinderbox and poudriere users do need to rebuild all their packages from
> scratch.

Does this mean rebuilding is necessary only if either tinderbox or
poudriere are used, or all packages have to be rebuilt anyway if pkgng
is used?

Best Regards.

---
Yasuhiro KIMURA
___
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 vertical split

2013-12-28 Thread Zsolt Udvari 
2013/12/28 James Griffin :
> yeah, it's in the docs I found online, although not in the man page on
> FreeBSD.
Ahh. I don't find it in FreeBSD's manpage.
I'm using tmux but installed now screen and as I see there's not vertical split.
___
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"

[QAT] r337877: 2x leftovers, 2x fetch

2013-12-28 Thread Ports-QAT 
Add devel/shtk.

The Shell Toolkit (shtk) is an application toolkit for programmers
writing POSIX-compliant shell scripts.

shtk provides a collection of reusable modules that work on a wide
variety of operating systems and shell interpreters.  The included
modules aid developers in implementing usable and consistent CLI
interfaces, interacting with processes, parsing configuration files
and manipulating higher-level data types among other things.

Reviewed by:rpaulo (ex-mentor)
Approved by:bdrewery (ports)
-

  Build ID:  20131228160201-45624
  Job owner: j...@freebsd.org
  Buildtime: 6 minutes
  Enddate:   Sat, 28 Dec 2013 16:07:36 GMT

  Revision:  r337877
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=337877

-

Port:devel/shtk 1.3

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   FETCH
  Log: 
https://qat.redports.org//~j...@freebsd.org/20131228160201-45624-244848/shtk-1.3.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   FETCH
  Log: 
https://qat.redports.org//~j...@freebsd.org/20131228160201-45624-244849/shtk-1.3.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~j...@freebsd.org/20131228160201-45624-244850/shtk-1.3.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~j...@freebsd.org/20131228160201-45624-244851/shtk-1.3.log


--
Buildarchive URL: 
redports 
___
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 vertical split

2013-12-28 Thread James Griffin 


On 12/28/2013 15:53, Zsolt Udvari wrote:

It is a documented command so i'm not sure why a patch would be necessary

The _vertical_ split?
yeah, it's in the docs I found online, although not in the man page on 
FreeBSD.

___
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 vertical split

2013-12-28 Thread Zsolt Udvari 
> It is a documented command so i'm not sure why a patch would be necessary
The _vertical_ split?
___
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 vertical split

2013-12-28 Thread James Griffin 


On 12/28/2013 15:32, Zsolt Udvari wrote:

Sorry, maybe my information is outdated. There is a patch and I think
ubuntu [1] uses this patch. Check:
curl 
http://archive.ubuntu.com/ubuntu/pool/main/s/screen/screen_4.0.3-14ubuntu10.diff.gz
| gzcat | grep vertic

[1] http://packages.ubuntu.com/saucy/screen



It is a documented command so i'm not sure why a patch would be necessary
___
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 vertical split

2013-12-28 Thread Zsolt Udvari 
Sorry, maybe my information is outdated. There is a patch and I think
ubuntu [1] uses this patch. Check:
curl 
http://archive.ubuntu.com/ubuntu/pool/main/s/screen/screen_4.0.3-14ubuntu10.diff.gz
| gzcat | grep vertic

[1] http://packages.ubuntu.com/saucy/screen

2013/12/28 James Griffin :
>
> On 12/28/2013 13:53, Zsolt Udvari wrote:
>>
>> As I know it's impossible in screen, see [1].
>> This was the main reason why I choose tmux.
>>
>> [1]
>> http://unix.stackexchange.com/questions/26685/how-to-split-window-vertically-in-gnu-screen
>>
>>
>> 2013/12/28 Jakob Breivik Grimstveit :
>>>
>>> How do I split screen vertically? Neither "Ctrl+a, |" nor "Ctrl+a V"
>>> seems
>>> to work...
>>>
>
> I too wondered about this. I just put it down to a problem with the port
> that would get fixed at some point; so, is it something that won't be
> possible on FreeBSD? I also have a similar problem with tmux: the vertical
> pane divider doesn't accept the colours defined in the configuration file,
> and even with no configuration file it shows as though the pane have split a
> second time when the haven't. Same in xterm and console.
>
> ___
> 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: Screen vertical split

2013-12-28 Thread James Griffin 


On 12/28/2013 13:53, Zsolt Udvari wrote:

As I know it's impossible in screen, see [1].
This was the main reason why I choose tmux.

[1] 
http://unix.stackexchange.com/questions/26685/how-to-split-window-vertically-in-gnu-screen


2013/12/28 Jakob Breivik Grimstveit :

How do I split screen vertically? Neither "Ctrl+a, |" nor "Ctrl+a V" seems
to work...



I too wondered about this. I just put it down to a problem with the port 
that would get fixed at some point; so, is it something that won't be 
possible on FreeBSD? I also have a similar problem with tmux: the 
vertical pane divider doesn't accept the colours defined in the 
configuration file, and even with no configuration file it shows as 
though the pane have split a second time when the haven't. Same in xterm 
and console.

___
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"

[HEADSUP] recursive dependency registration is gone for pkgng users

2013-12-28 Thread Baptiste Daroussin 
Hi all,

With r337100, we do stop registering recursively the dependency.

As a result the dependency tracking is better and finer grain, as a side effect,
tinderbox and poudriere users do need to rebuild all their packages from
scratch.

For poudriere pass the -c to the bulk option.

regards,
Bapt


pgpfdpbvtzCcZ.pgp
Description: PGP signature

Re: Screen vertical split

2013-12-28 Thread Zsolt Udvari 
As I know it's impossible in screen, see [1].
This was the main reason why I choose tmux.

[1] 
http://unix.stackexchange.com/questions/26685/how-to-split-window-vertically-in-gnu-screen


2013/12/28 Jakob Breivik Grimstveit :
> How do I split screen vertically? Neither "Ctrl+a, |" nor "Ctrl+a V" seems
> to work...
>
>
> --
> Vyrdsamt,
> Jakob Breivik Grimstveit | +47 4829 8152
> http://grimstveit.no/jakob
> ___
> 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"

Screen vertical split

2013-12-28 Thread Jakob Breivik Grimstveit 
How do I split screen vertically? Neither "Ctrl+a, |" nor "Ctrl+a V" seems
to work...


-- 
Vyrdsamt,
Jakob Breivik Grimstveit | +47 4829 8152
http://grimstveit.no/jakob
___
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: gtkglext

2013-12-28 Thread Tijl Coosemans 
On Sat, 28 Dec 2013 06:36:28 -0500 Ajtim wrote:
> I want to update pdfcube which need gtkglext and I got an error but I
> DON'T WISH to deinstall ot force pkg register. I think this a forth
> porth which need "force pkg register".

I've committed a fix to print/pdfcube in r337872.
___
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"

gtkglext

2013-12-28 Thread Ajtim 
Hi!

My system:
FreeBSD 10.0-RC3 #0 r259778: Mon Dec 23 23:27:58 UTC 2013 
r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

I want to update pdfcube which need gtkglext and I got an error but I DON'T 
WISH to deinstall ot force pkg register. I think this a forth porth which need 
"force pkg register".

===>  Cleaning for pdfcube-0.0.5_1
===>   pdfcube-0.0.5_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by pdfcube-0.0.5_1 for building
===>  Extracting for pdfcube-0.0.5_1
=> SHA256 Checksum OK for pdfcube-0.0.5.tar.gz.
===>  Patching for pdfcube-0.0.5_1
/usr/bin/sed -i.bak -e  
's|BOOSTLIBDIR/libboost_program_options\*\.{so,a}\*|BOOSTLIBDIR/libboost_program_options.so|'
  /usr/ports/print/pdfcube/work/pdfcube-0.0.5/configure
===>   pdfcube-0.0.5_1 depends on executable: pkgconf - found
===>   pdfcube-0.0.5_1 depends on shared library: libgtkglext.so - not found
===>Verifying for libgtkglext.so in /usr/ports/x11-toolkits/gtkglext
===>  Installing for gtkglext-1.2.0_13
===>   gtkglext-1.2.0_13 depends on file: /usr/local/libdata/pkgconfig/ice.pc - 
found
===>   gtkglext-1.2.0_13 depends on file: 
/usr/local/libdata/pkgconfig/pixman-1.pc - found
===>   gtkglext-1.2.0_13 depends on file: /usr/local/libdata/pkgconfig/sm.pc - 
found
===>   gtkglext-1.2.0_13 depends on file: /usr/local/libdata/pkgconfig/x11.pc - 
found
===>   gtkglext-1.2.0_13 depends on file: /usr/local/libdata/pkgconfig/xau.pc - 
found
===>   gtkglext-1.2.0_13 depends on file: /usr/local/libdata/pkgconfig/xcb.pc - 
found
===>   gtkglext-1.2.0_13 depends on file: 
/usr/local/libdata/pkgconfig/xcomposite.pc - found
===>   gtkglext-1.2.0_13 depends on file: 
/usr/local/libdata/pkgconfig/xcursor.pc - found
===>   gtkglext-1.2.0_13 depends on file: 
/usr/local/libdata/pkgconfig/xdamage.pc - found
===>   gtkglext-1.2.0_13 depends on file: /usr/local/libdata/pkgconfig/xdmcp.pc 
- found
===>   gtkglext-1.2.0_13 depends on file: /usr/local/libdata/pkgconfig/xext.pc 
- found
===>   gtkglext-1.2.0_13 depends on file: 
/usr/local/libdata/pkgconfig/xfixes.pc - found
===>   gtkglext-1.2.0_13 depends on file: /usr/local/libdata/pkgconfig/xi.pc - 
found
===>   gtkglext-1.2.0_13 depends on file: 
/usr/local/libdata/pkgconfig/xinerama.pc - found
===>   gtkglext-1.2.0_13 depends on file: /usr/local/libdata/pkgconfig/xmu.pc - 
found
===>   gtkglext-1.2.0_13 depends on file: 
/usr/local/libdata/pkgconfig/xrandr.pc - found
===>   gtkglext-1.2.0_13 depends on file: 
/usr/local/libdata/pkgconfig/xrender.pc - found
===>   gtkglext-1.2.0_13 depends on file: /usr/local/libdata/pkgconfig/xt.pc - 
found
===>   gtkglext-1.2.0_13 depends on file: 
/usr/local/libdata/pkgconfig/xxf86vm.pc - found
===>   gtkglext-1.2.0_13 depends on shared library: libpthread-stubs.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libpcre.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libcairo.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libdrm.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libpng15.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libfreetype.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libexpat.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libfontconfig.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libintl.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libGLU.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libatk-1.0.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libgdk_pixbuf-2.0.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libglib-2.0.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libpcre.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libgtk-x11-2.0.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libpango-1.0.so - found
===>   gtkglext-1.2.0_13 depends on shared library: libpangox-1.0.so - found
===>  Checking if x11-toolkits/gtkglext already installed
===>   gtkglext-1.2.0_13 is already installed
  You may wish to ``make deinstall'' and install this port again
  by ``make reinstall'' to upgrade it properly.
  If you really wish to overwrite the old port of x11-toolkits/gtkglext
  without deleting it first, set the variable "FORCE_PKG_REGISTER"
  in your environment or the "make install" command line.
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/x11-toolkits/gtkglext
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/x11-toolkits/gtkglext
*** Error code 1

Stop.
make: stopped in /usr/ports/print/pdfcube

===>>> make failed for print/pdfcube
===>>> Aborting update

===>>> Update for print/pdfcube failed
===>>> Aborting update

===>>> Killing background jobs
Terminated

===>>> You can restart from the point of failure with this command line:
   portmaster  print/pdfcube 

-- 
Mitja
---
http://www.redbubble.com/people/lumiwa

_

Re: dns/bind* ports overwriting conf files

2013-12-28 Thread Mathieu Arnold 
+--On 27 décembre 2013 17:18:43 -0800 Doug Barton 
wrote:
| What I proposed as part of this work years ago was to create something
| like a bind-config package that would (optionally) install the same
| default files and configuration for the port that are still in the base
| for [89].x. That way users who just wanted the old default local resolver
| could get that behavior easily, and users with other needs would not have
| to have it. I still think that's the easiest and least painful way to
| manage the transition, and would encourage Erwin to consider it. (For
| extra credit, a different but similar sort of port should be created to
| enable DNSSEC validation, and should include the root zone trust anchor,
| and a description of how the user can validate it for themselves.)

That's some interesting ideas, yes, the maintainer of bind will certainly
keep them in mind, whoever he is in the future. Having the possibility of
get sub packages and flavors in a few months will really help in that way.

| In any case even a _plan_ to overwrite conf files blindly is a bad idea.
| So much the better to fix it now before it actually bites any users.

Yes, it was, and it was fixed as soon as Erwin learnt about it. What I was
saying is that it only appears on freebsd where bind was absent from the
base, which, at that time was 10.0-BETAsomething or 11-CURRENT. I know it
was a *big* bug, but the impact was small because the os versions were not
releases.

-- 
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: ntp-devel-4.2.7p364_2 coredumps

2013-12-28 Thread Stefan Bethke 
Am 28.12.2013 um 06:13 schrieb Cy Schubert :

> In message , Stefan Bethke 
> wri
> tes:
>> 
>> --Apple-Mail=_6EEA81A7-5FCB-41CB-A6F5-4CBEDAB3BBAE
>> Content-Transfer-Encoding: quoted-printable
>> Content-Type: text/plain;
>>  charset=us-ascii
>> 
>> On both 9-stable and 10-stable
>> 
>> Dec 26 13:02:04 lokschuppen ntpd[5270]: ntpd 4.2.7p364@1.2483-o Thu Dec =
>> 26 12:55:22 UTC 2013 (1): Starting
>> Dec 26 13:02:04 lokschuppen ntpd[5270]: Command line: =
>> /usr/local/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -f =
>> /var/db/ntpd.drift
>> Dec 26 13:02:05 lokschuppen kernel: pid 5271 (ntpd), uid 0: exited on =
>> signal 11 (core dumped)
> 
> p404 has just been committed. Let's see if it makes a difference.
> 
> Let me know what uname -a shows and any options/optional modules compiled 
> or loaded.

That seems to have done the trick, thank you!

The problem occurred on both
FreeBSD diesel.lassitu.de 10.0-PRERELEASE FreeBSD 10.0-PRERELEASE #5 r259696: 
Sun Dec 22 00:13:23 CET 2013 
r...@diesel.lassitu.de:/usr/obj/var/freebsd/10-stable/sys/DIESEL  amd64
and
FreeBSD lokschuppen.zs64.net 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #2 r255602: 
Sun Sep 15 21:25:57 UTC 2013 
r...@lokschuppen.zs64.net:/usr/obj/freebsd/checkout/src/sys/EISENBOOT  amd64
with defaults for the port:
# make showconfig
===> The following configuration options are available for ntp-devel-4.2.7p404:
 ACTS=off: Enable ACTS modem service
 ARBITER=off: Enable Arbiter 1088A/B GPS receiver
 ARCRON_MSF=off: Enable Arcron MSF receiver
 AS2201=off: Enable Austron 2200A/2201A GPS receiver
 ATOM=on: Enable ATOM PPS interface
 AUDIO_CHU=off: Enable CHU audio/decoder
 BANCOMM=off: Enable Datum/Bancomm bc635/VME interface
 CHRONOLOG=off: Enable Chrono-log K-series WWVB receiver
 CHU=off: Enable CHU modem/decoder
 COMPUTIME=off: Enable Diem Computime Radio Clock
 DATUM=off: Enable Datum Programmable Time System
 DCF7000=off: Enable ELV/DCF7000 clock
 DUMBCLOCK=off: Enable Dumb generic hh:mm:ss local clock
 FG=off: Enable Forum Graphic GPS
 GPSVME=off: Enable TrueTime GPS receiver/VME interface
 HEATH=off: Enable Heath GC-1000 WWV/WWVH receiver
 HOPF6021=off: Enable HOPF 6021 clock
 HOPFPCI=off: Enable hopf 6039 PCI board
 HOPFSERIAL=off: Enable hopf serial clock device
 HPGPS=off: Enable HP 58503A GPS receiver
 IPV6=on: IPv6 protocol support
 IRIG=off: Enable IRIG audio decoder
 JJY=off: Enable JJY receiver
 JUPITER=off: Enable Rockwell Jupiter GPS receiver
 LEITCH=off: Enable Leitch CSD 5300 Master Clock
 LOCAL_CLOCK=off: Enable local clock reference
 MEINBERG=off: Enable Meinberg clocks
 MX4200=off: Enable Magnavox MX4200 GPS receiver
 NEOCLOCK4X=off: Enable NeoClock4X DCF77 / TDF receiver
 NMEA=on: Enable NMEA GPS receiver
 NTPSNMPD=off: Build and install ntpsnmpd
 NTP_SIGND=on: Enable signed NTP
 ONCORE=off: Enable Motorola VP/UT Oncore GPS receiver
 PALISADE=off: Enable Palisade clock
 PCF=off: Enable Conrad parallel port radio clock
 PST=off: Enable PST/Traconex 1020 WWV/WWVH receiver
 RAWDCF=off: Enable DCF77 raw time code
 RCC8000=off: Enable RCC 8000 clock
 RIPENCC=off: Enable RIPENCC specific Trimble driver
 SCHMID=off: Enable Schmid DCF77 clock
 SEL240X=off: Enable SEL 240X clocks
 SHM=off: Enable SHM clock attached thru shared memory
 SPECTRACOM=off: Enable Spectracom 8170/Netclock/2 WWVB
 SSL=on: SSL protocol support
 TRIMTAIP=off: Enable Trimble GPS receiver/TAIP protocol
 TRIMTSIP=off: Enable Trimble GPS receiver/TSIP protocol
 TRUETIME=off: Enable Kinemetrics/TrueTime receivers
 ULINK=off: Enable Ultralink WWVB receiver
 VARITEXT=off: Enable VARITEXT clock
 WHARTON=off: Enable WHARTON 400A Series clock
 WWV=off: Enable WWV Audio receiver
 ZYFER=off: Enable Zyfer GPStarplus receiver
===> Use 'make config' to modify these settings
-- 
Stefan BethkeFon +49 151 14070811






signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [QAT] r337727: 4x leftovers, 16x success

2013-12-28 Thread Philippe Audéoud 
Hi
Leftovers are from irssi, not from my port.

Regards


Ports-QAT  a écrit :
>- Support STAGE
>-
>
>  Build ID:  20131227131000-20162
>  Job owner: jada...@freebsd.org
>  Buildtime: 12 hours
>  Enddate:   Sat, 28 Dec 2013 00:41:33 GMT
>
>  Revision:  r337727
>Repository:   
>https://svnweb.freebsd.org/ports?view=revision&revision=337727
>
>-
>
>Port:editors/hexcurse 1.55
>
>  Buildgroup: 8.4-QAT/amd64
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244164/hexcurse-1.55.log
>
>  Buildgroup: 8.4-QAT/i386
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244165/hexcurse-1.55.log
>
>  Buildgroup: 9.2-QAT/amd64
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244166/hexcurse-1.55.log
>
>  Buildgroup: 9.2-QAT/i386
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244167/hexcurse-1.55.log
>
>-
>
>Port:games/banihstypos 0.2
>
>  Buildgroup: 8.4-QAT/amd64
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244168/banihstypos-0.2.log
>
>  Buildgroup: 8.4-QAT/i386
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244169/banihstypos-0.2.log
>
>  Buildgroup: 9.2-QAT/amd64
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244170/banihstypos-0.2.log
>
>  Buildgroup: 9.2-QAT/i386
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244171/banihstypos-0.2.log
>
>-
>
>Port:irc/irssi-xmpp 0.52
>
>  Buildgroup: 8.4-QAT/amd64
>  Buildstatus:   LEFTOVERS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244172/irssi-xmpp-0.52.log
>
>  Buildgroup: 8.4-QAT/i386
>  Buildstatus:   LEFTOVERS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244173/irssi-xmpp-0.52.log
>
>  Buildgroup: 9.2-QAT/amd64
>  Buildstatus:   LEFTOVERS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244174/irssi-xmpp-0.52.log
>
>  Buildgroup: 9.2-QAT/i386
>  Buildstatus:   LEFTOVERS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244175/irssi-xmpp-0.52.log
>
>-
>
>Port:mail/vrfy 1.0_1
>
>  Buildgroup: 8.4-QAT/amd64
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244176/vrfy-1.0_1.log
>
>  Buildgroup: 8.4-QAT/i386
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244177/vrfy-1.0_1.log
>
>  Buildgroup: 9.2-QAT/amd64
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244178/vrfy-1.0_1.log
>
>  Buildgroup: 9.2-QAT/i386
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244179/vrfy-1.0_1.log
>
>-
>
>Port:math/p5-Math-BaseCalc 1.017
>
>  Buildgroup: 8.4-QAT/amd64
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244180/p5-Math-BaseCalc-1.017.log
>
>  Buildgroup: 8.4-QAT/i386
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244181/p5-Math-BaseCalc-1.017.log
>
>  Buildgroup: 9.2-QAT/amd64
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244182/p5-Math-BaseCalc-1.017.log
>
>  Buildgroup: 9.2-QAT/i386
>  Buildstatus:   SUCCESS
>Log:
>https://qat.redports.org//~jada...@freebsd.org/20131227131000-20162-244183/p5-Math-BaseCalc-1.017.log
>
>
>--
>Buildarchive URL:
>
>redports 

-- 
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
___
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"