FreeBSD Quarterly Status Report - Third Quarter 2014
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 FreeBSD Project Quarterly Status Report: July - September 2014 This report covers FreeBSD-related projects between July and September 2014. This is the third of four reports planned for 2014. The third quarter of 2014 was another productive quarter for the FreeBSD project. A lot of work has been done on various ARM platforms, with the goal of bringing them to Tier 1 status in FreeBSD 11. The various ports teams have also worked hard to improve the state of FreeBSD as a desktop operating system. As usual, performance improvements feature in several places in this report and many of these can benefit from user benchmarking to validate our results. Thanks to all the reporters for the excellent work! The deadline for submissions covering the period from October to December 2014 is January 7th, 2015. __ FreeBSD Team Reports * FreeBSD Cluster Administration Team * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team Projects * Address Space Layout Randomization (ASLR) * amd64 Xen Paravirtualization * bhyve * Chelsio iSCSI Offload Support * Debian GNU/kFreeBSD * FreeBSD Preseed Installation (PXE) * Jenkins Continuous Integration for FreeBSD * New Automounter * QEMU bsd-user-Enabled Ports Building * VMWare VAAI and Microsoft ODX Acceleration in CTL * ZFSguru Kernel * Intel GPU Driver Update * SDIO Driver * UEFI Boot * Updated vt(4) System Console * Updating OpenCrypto Architectures * FreeBSD on Newer ARM Boards * FreeBSD/arm64 Userland Programs * LLDB Debugger Port * LLVM Address Sanitizer (Asan) * SSE Variants of libc Routines for amd64 Ports * FreeBSD Python Ports * GNOME/FreeBSD * KDE on FreeBSD * The Graphics Stack on FreeBSD * Xfce Documentation * Handbook ezjail Section * Michael Lucas Books * ZFS Chapter of the Handbook Miscellaneous * The FreeBSD Foundation __ FreeBSD Cluster Administration Team Contact: FreeBSD Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on: * Implemented a central, FreeBSD cluster-specific package building node using ports-mgmt/poudriere-devel, providing a single consistent set of third-party binary packages throughout the FreeBSD cluster from a common, known-working configuration. * Converted all machines running in the FreeBSD cluster from individual (and sometimes different) userland and kernel configurations to a single configuration for the base system. This enabled the implementation of a FreeBSD.org-specific binary update mechanism currently deployed throughout the cluster. This project is sponsored by The FreeBSD Foundation . __ FreeBSD Release Engineering Team URL: http://www.freebsd.org/releases/10.1R/schedule.html URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. In mid-July, FreeBSD 9.3-RELEASE was released without delay in release cycle. In late August, the FreeBSD 10.1-RELEASE cycle began, and as of this writing, is expected to stay on schedule. Work to produce virtual machine images as part of the release cycle has continued, supporting various cloud services such as Microsoft Azure, Amazon EC2, and Google Compute Engine. This project is sponsored by The FreeBSD Foundation . __ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.freebsd.org/index.html URL: http://portscout.freebsd.org/ URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: Port Management Team As of the end of Q3, the ports tree holds a bit more than 24,000 ports, and the PR count is below 1,400. Despite the summer holidays the tree saw sustained activity with more than
Re: printing text file with LPD - non-printable characters
@Don: > I think it (cups) also broke for me around that timeframe until I > found that I also needed cups-filters. You sir, are a life saver! Thank you for the tip. [SOLVED] - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/printing-text-file-with-LPD-non-printable-characters-tp5954561p5956782.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: installincludes, bsd.incs.mk and param.h
On Tue, 2014-10-14 at 18:09 +0200, Harald Schmalzbauer wrote: > Bezüglich Ian Lepore's Nachricht vom 14.10.2014 17:37 (localtime): > ... > > It appears that while bsd.ports.mk has lost the ability to use the > > version of the running system (sysctl kern.osreldate), it still has the > > logic to just use OSVERSION if it's already set on the make command line > > or in the environment. Can you leverage that to regain the behavior > > you're used to? > > In general yes, that's what I did since my last ports-svn-update, but > only to avoid complete breakage. > Problem is that I have absolutely not in mind what OSVERSION on what > machine to set. So I'm supplying a "dummy" version. That shouldn't be a > problem for my purposes, but it's simply wrong. This check was > introduced to gather the »correct« OSVERSION ;-) And manually supplying > the correct version doesn't work due to brain contraints ;-) > I like the idea to ask a userland installed indicator. But I'm not > familar enough with bsd.incs.mk and the related installworld stage. I'd > just need the hint from where include/Makefile gets conditionally > (MK_TOOLCCHAIN!=no) included ... ?!? Somwhere it start's recursing the > SUBDIRs, and I guess every binary calls installincludes: from it's > directory (which works since bsd.lib.mk and bsd.prog.mk include > bsd.incs.mk), but I can't find at what SUBDIR param.h is involved. > > Thanks, > > -Harry > The old code that used to work for you got the version via sysctl, so I was recommending that you keep doing that yourself, since it's no longer built in to bsd.ports.mk. So just add "export OSVERSION=`sysctl kern.osreldate` to your script that kicks off this update process, something like that. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: printing text file with LPD - non-printable characters
On 14 Oct, Beeblebrox wrote: >> We are using in production environments CUPS in the version 1.4.3; >> this has a component 'texttops' which supports UTF-8 encoded text >> (only) and prints UTF-8 nicely on the fly. > > Thanks for the input. > Unfortunately, CUPS has been broken for me since May/14. > (http://freebsd.1045724.n5.nabble.com/print-cups-base-web-interface-broken-amp-unable-to-print-td5918098.html#a5922974) > > Installed CUPS components: > cups-base-1.7.3_1, cups-client-1.7.3_2, cups-image-1.7.3_1, cups-pdf-2.6.1_1, > cups-pstoraster-8.15.4_8, gutenprint-cups-5.2.10 I think it also broke for me around that timeframe until I found that I also needed cups-filters. cups-base-1.7.3_1 Common UNIX Printing System: Server cups-client-1.7.3_2Common UNIX Printing System: Library cups cups-filters-1.0.58Backends, filters and other software (was part of the core CUPS) cups-image-1.7.3_1 Common UNIX Printing System: Library cupsimage cups-pstoraster-8.15.4_8 Postscript interpreter for CUPS printing to non-PS printers gutenprint-cups-5.2.10 GutenPrint Printer Driver libgnomecups-0.2.3_6,1 Support library for gnome cups administration ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: installincludes, bsd.incs.mk and param.h
Bezüglich Ian Lepore's Nachricht vom 14.10.2014 17:37 (localtime): ... > It appears that while bsd.ports.mk has lost the ability to use the > version of the running system (sysctl kern.osreldate), it still has the > logic to just use OSVERSION if it's already set on the make command line > or in the environment. Can you leverage that to regain the behavior > you're used to? In general yes, that's what I did since my last ports-svn-update, but only to avoid complete breakage. Problem is that I have absolutely not in mind what OSVERSION on what machine to set. So I'm supplying a "dummy" version. That shouldn't be a problem for my purposes, but it's simply wrong. This check was introduced to gather the »correct« OSVERSION ;-) And manually supplying the correct version doesn't work due to brain contraints ;-) I like the idea to ask a userland installed indicator. But I'm not familar enough with bsd.incs.mk and the related installworld stage. I'd just need the hint from where include/Makefile gets conditionally (MK_TOOLCCHAIN!=no) included ... ?!? Somwhere it start's recursing the SUBDIRs, and I guess every binary calls installincludes: from it's directory (which works since bsd.lib.mk and bsd.prog.mk include bsd.incs.mk), but I can't find at what SUBDIR param.h is involved. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: installincludes, bsd.incs.mk and param.h
On Tue, 2014-10-14 at 17:24 +0200, Harald Schmalzbauer wrote: > Bezüglich David Wolfskill's Nachricht vom 14.10.2014 16:52 (localtime): > > On Tue, Oct 14, 2014 at 04:42:57PM +0200, Harald Schmalzbauer wrote: > >> Hello, > >> > >> since bsd.port.mk insinsts on param.h, I have inconveniences on my > >> production systems which were installed with "WITHOUT_TOOLCHAIN=true" in > >> src.conf (resulting in MK_TOOLCHAIN=no). > >> > >> My first attempt was the following patch: > >> ... > >> "$SYSDIR" makes the example above not working! > >> Unfortunately I couldn't figure out when/how param.h gets installed. > >> Also, I couldn't find out what stage uses include/Makefile, only that > >> it's not used when MK_TOOLCHAIN=no. > >> > >> Any help highly appreciated! > >> > > My production systems have their OS built on a "build machine"; at > > install time, the build machine exports its /usr/src and /usr/obj, and I > > "make installkernel installworld" (& mergemaster...) on the production > > systems. > > > > I'm still building ports using portmaster on the production systems (as > > I lack the infrastructure to create my own pkg repository, and I need > > some non-default options), so I export the build machine's /usr/src & > > /usr/obj to the production machines during the ports builds, as well. > > > > That said, I don't try to do anything with respect to MK_TOOLCHAIN -- in > > normal use, the production machines don't have /usr/src or /usr/obj at > > all anyway. > > > > In any case, this has generally been working for me for many years. > > Sounds reasonable. For one (big) enivronment at least. > I have different, completely unrelated environments which I maintain. > Therefore I do have a complete project-oriented build- and rollout > infrastruture, which also handles ports/packages (most times distributed > as repository on CD, each CD a set of applications for one distinct > machine). > > So on my production systems, I don't need to (and even can't) compile > any sources, but on some of them, I often use the ports tree for update > checks or various - destination machine unrelated - tasks, like 'make > fetch' for having a convenient way looking into sources e.g. ... > The ports tree has been a very valuable source for me in many aspects, > not just for compiling anything. > > The param.h dependent OSVERSION check is relatively new, but bites me > frequently. So I really need a possibility to make the ports tree usable > again on machines which don't have any part of TOOLCHAIN installed. > Preferably I'd like to "fix" the dependency as close as possible to the > FreeBSD standard build environment, instead of botching post-installworld... > > Thanks, > > -Harry > > > It appears that while bsd.ports.mk has lost the ability to use the version of the running system (sysctl kern.osreldate), it still has the logic to just use OSVERSION if it's already set on the make command line or in the environment. Can you leverage that to regain the behavior you're used to? -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: installincludes, bsd.incs.mk and param.h
Bezüglich David Wolfskill's Nachricht vom 14.10.2014 16:52 (localtime): > On Tue, Oct 14, 2014 at 04:42:57PM +0200, Harald Schmalzbauer wrote: >> Hello, >> >> since bsd.port.mk insinsts on param.h, I have inconveniences on my >> production systems which were installed with "WITHOUT_TOOLCHAIN=true" in >> src.conf (resulting in MK_TOOLCHAIN=no). >> >> My first attempt was the following patch: >> ... >> "$SYSDIR" makes the example above not working! >> Unfortunately I couldn't figure out when/how param.h gets installed. >> Also, I couldn't find out what stage uses include/Makefile, only that >> it's not used when MK_TOOLCHAIN=no. >> >> Any help highly appreciated! >> > My production systems have their OS built on a "build machine"; at > install time, the build machine exports its /usr/src and /usr/obj, and I > "make installkernel installworld" (& mergemaster...) on the production > systems. > > I'm still building ports using portmaster on the production systems (as > I lack the infrastructure to create my own pkg repository, and I need > some non-default options), so I export the build machine's /usr/src & > /usr/obj to the production machines during the ports builds, as well. > > That said, I don't try to do anything with respect to MK_TOOLCHAIN -- in > normal use, the production machines don't have /usr/src or /usr/obj at > all anyway. > > In any case, this has generally been working for me for many years. Sounds reasonable. For one (big) enivronment at least. I have different, completely unrelated environments which I maintain. Therefore I do have a complete project-oriented build- and rollout infrastruture, which also handles ports/packages (most times distributed as repository on CD, each CD a set of applications for one distinct machine). So on my production systems, I don't need to (and even can't) compile any sources, but on some of them, I often use the ports tree for update checks or various - destination machine unrelated - tasks, like 'make fetch' for having a convenient way looking into sources e.g. ... The ports tree has been a very valuable source for me in many aspects, not just for compiling anything. The param.h dependent OSVERSION check is relatively new, but bites me frequently. So I really need a possibility to make the ports tree usable again on machines which don't have any part of TOOLCHAIN installed. Preferably I'd like to "fix" the dependency as close as possible to the FreeBSD standard build environment, instead of botching post-installworld... Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: installincludes, bsd.incs.mk and param.h
On Tue, Oct 14, 2014 at 04:42:57PM +0200, Harald Schmalzbauer wrote: > Hello, > > since bsd.port.mk insinsts on param.h, I have inconveniences on my > production systems which were installed with "WITHOUT_TOOLCHAIN=true" in > src.conf (resulting in MK_TOOLCHAIN=no). > > My first attempt was the following patch: > ... > "$SYSDIR" makes the example above not working! > Unfortunately I couldn't figure out when/how param.h gets installed. > Also, I couldn't find out what stage uses include/Makefile, only that > it's not used when MK_TOOLCHAIN=no. > > Any help highly appreciated! > My production systems have their OS built on a "build machine"; at install time, the build machine exports its /usr/src and /usr/obj, and I "make installkernel installworld" (& mergemaster...) on the production systems. I'm still building ports using portmaster on the production systems (as I lack the infrastructure to create my own pkg repository, and I need some non-default options), so I export the build machine's /usr/src & /usr/obj to the production machines during the ports builds, as well. That said, I don't try to do anything with respect to MK_TOOLCHAIN -- in normal use, the production machines don't have /usr/src or /usr/obj at all anyway. In any case, this has generally been working for me for many years. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpZr45fxRLgO.pgp Description: PGP signature
installincludes, bsd.incs.mk and param.h
Hello,
since bsd.port.mk insinsts on param.h, I have inconveniences on my
production systems which were installed with "WITHOUT_TOOLCHAIN=true" in
src.conf (resulting in MK_TOOLCHAIN=no).
My first attempt was the following patch:
--- share/mk/bsd.incs.mk.orig 2014-10-14 16:35:53.0 +0200
+++ share/mk/bsd.incs.mk2014-10-14 16:34:57.0 +0200
@@ -81,4 +81,9 @@
realinstall: installincludes
.ORDER: beforeinstall installincludes
+.else
+installincludes:
+${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
+${SYSDIR}/sys/param.h ${DESTDIR}${INCLUDEDIR}/sys/sys
+
.endif # !defined(NO_INCS) && ${MK_TOOLCHAIN} != "no"
"$SYSDIR" makes the example above not working!
Unfortunately I couldn't figure out when/how param.h gets installed.
Also, I couldn't find out what stage uses include/Makefile, only that
it's not used when MK_TOOLCHAIN=no.
Any help highly appreciated!
Thanks,
-Harry
signature.asc
Description: OpenPGP digital signature
Re: printing text file with LPD - non-printable characters
El día Tuesday, October 14, 2014 a las 03:07:10AM -0700, Beeblebrox escribió: > @Matthias: I'm not '@Matthias', but Matthias, and I think, the @ sign is normaly used to express user@host or @domain; > > This is one of the reasons we stick with 1.4.3. > > How? Did you create a self-maintained port for it? > How did you overcome the problem of CUPS-dependent ports pulling in 1.7.3 in > poudriere? I compile it directly from source, also on non-FreeBSD hosts (Linux and SPARC) and ship it to our customers. matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: printing text file with LPD - non-printable characters
@Matthias: > This is one of the reasons we stick with 1.4.3. How? Did you create a self-maintained port for it? How did you overcome the problem of CUPS-dependent ports pulling in 1.7.3 in poudriere? Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/printing-text-file-with-LPD-non-printable-characters-tp5954561p5956672.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: printing text file with LPD - non-printable characters
El día Tuesday, October 14, 2014 a las 02:26:37AM -0700, Beeblebrox escribió: > > We are using in production environments CUPS in the version 1.4.3; > > this has a component 'texttops' which supports UTF-8 encoded text > > (only) and prints UTF-8 nicely on the fly. > > Thanks for the input. > Unfortunately, CUPS has been broken for me since May/14. > (http://freebsd.1045724.n5.nabble.com/print-cups-base-web-interface-broken-amp-unable-to-print-td5918098.html#a5922974) > > Installed CUPS components: > cups-base-1.7.3_1, cups-client-1.7.3_2, cups-image-1.7.3_1, cups-pdf-2.6.1_1, > cups-pstoraster-8.15.4_8, gutenprint-cups-5.2.10 This is one of the reasons we stick with 1.4.3. matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: printing text file with LPD - non-printable characters
> We are using in production environments CUPS in the version 1.4.3; > this has a component 'texttops' which supports UTF-8 encoded text > (only) and prints UTF-8 nicely on the fly. Thanks for the input. Unfortunately, CUPS has been broken for me since May/14. (http://freebsd.1045724.n5.nabble.com/print-cups-base-web-interface-broken-amp-unable-to-print-td5918098.html#a5922974) Installed CUPS components: cups-base-1.7.3_1, cups-client-1.7.3_2, cups-image-1.7.3_1, cups-pdf-2.6.1_1, cups-pstoraster-8.15.4_8, gutenprint-cups-5.2.10 Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/printing-text-file-with-LPD-non-printable-characters-tp5954561p5956658.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: printing text file with LPD - non-printable characters
El día Tuesday, October 14, 2014 a las 01:19:42AM -0700, Beeblebrox escribió: > Enscript does not support UTF-8 formatted text files, so it's not usable in > this case. > > One solution, "is to use paps, instead of Enscript, for converting UTF-8 > encoded text to PostScript." > http://www.linuxfromscratch.org/blfs/view/svn/pst/enscript.html > > ... We are using in production environments CUPS in the version 1.4.3; this has a component 'texttops' which supports UTF-8 encoded text (only) and prints UTF-8 nicely on the fly. We have a special enhancement of the used fonts to support most EU languages. HIH matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: printing text file with LPD - non-printable characters
Enscript does not support UTF-8 formatted text files, so it's not usable in this case. One solution, "is to use paps, instead of Enscript, for converting UTF-8 encoded text to PostScript." http://www.linuxfromscratch.org/blfs/view/svn/pst/enscript.html Another (which I prefer) solution is to send to printer like this (with "n" being the 8859 extension number): $ iconv -f UTF-8 -t ISO-8859-n file-UTF8.txt | enscript --encoding=8859n | lpr -P Thanks to Martin Paredes for this suggestion. Perhaps this information or the appropriate enscript conversion code for psif could be included in the Handbook (https://www.freebsd.org/doc/handbook/printing-lpd.html 10.5.3.4 / 10.5.3.5)? Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/printing-text-file-with-LPD-non-printable-characters-tp5954561p5956648.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
