According to the submitter:
"Distfiles for print/py-freetype are no longer available. Author of
the software has been contacted and indicated the software is defunct."
PR: ports/104229
Submitted by: Josh Paetzel <josh@tcbug.org>
Update to 2.05
<GeJ> so, noone for ports/104228 before the freeze?
<Mavvie> I think that the right phrase should be "can somebody commit this PR for me"
PR: ports/104228
Submitted by: Geraud CONTINSOUZAS <geraud@gcu.info>
- Replace self-checksum with ports distinfo.
- Update "System Requirements" list in pkg-descr.
PR: ports/103829
Submitted by: Kevin Brunelle <kruptos@mlinux.org>
Geomgui is a viewer for the geom layer in the kernel written in C.
It can show the geom layout on the host computer or fetch info from
a remote system via ssh. It has the same arrow key bindings as fx, vi,
(h,j,k and l)and uses z to soom out and Z to zoom in, u is for updating.
WWW: http://geomgui.xride.dk
Approved by: tmclaugh (mentor)
- The usual assortment of MSI improvements.
- Several bug fixes to the various common controls.
- Pixel shaders enabled by default in D3D.
- Various improvements to the build process.
- Many translation updates.
- Lots of bug fixes.
(www.snort.org), an open source intrusion detection system.
The actual interface and GUI server are written in tcl/tk
(www.tcl.tk). Sguil also relies on other open source software
in order to function properly.
The sensor list includes security/barnyard, security/snort,
security/sancp, tcpdump (a part of the OS) and devel/tcltls as
well as lang/tcl84 and lang/tclX. Care has been taken to ensure
that everything you need to build a working sguil operation is
in the FreeBSD ports system or part of the OS already.
Sguil currently functions as an analysis interface and has
no snort sensor or rule management capabilities.
WWW: http://sguil.sourceforge.net/index.phppauls@utdallas.edu
PR: ports/95018
Submitted by: Paul Schmehl <pauls at utdallas.edu>
Revision 1.3 of patch-ad worked around the problem, that only one writer
is allowed to allow a partition through GEOM. The fix was not complete,
leading to the file position not been incremented during reads and writes,
thus not testing sequential performance, but performance of cached reads
and writes, in general.
This fix makes rawio report reasonable sequential performance again,
but I'm still very suspicious with regard to randomized start positions
working. The results do not show the expected variation of sequential
read/write performance. I have not had time to look into this any deeper,
though, and thus decidied to not delay the commit any further ...
