Just to make it official, the ports slush is over.
Ports committers are now able to perform regular updates, business as usual, no need for portmgr@ approvals.
You can read more at http://lists.freebsd.org/pipermail/freebsd-ports-announce/2013-April/000058.html
Just to make it official, the ports hard freeze has been lifted.
Ports committers are now able to perform regular updates, just no sweeping
commits without prior approval from portmgr. This period of slush will
continue until 8.4 is out the door.
Read more at http://lists.freebsd.org/pipermail/freebsd-ports-announce/2013-April/000056.html
The FreeBSD Ports Management Team wishes to remind users that February 28 was the end of support for the Ports Collection for both FreeBSD 7.4 RELEASE and the FreeBSD 7.x STABLE branch. Neither the infrastructure nor individual ports are guaranteed to work on these FreeBSD versions after that date. A tag has be created for users who cannot upgrade for some reason, at which time these users are advised to stop tracking the latest ports repository and use the RELEASE_7_EOL tag instead.
Read more at http://lists.freebsd.org/pipermail/freebsd-ports-announce/2013-March/000051.html
Mark Linimon, aka linimon@, Â recently stepped down from his duties on the FreeBSD Ports Management Team.
Mark joined the team back in 2004, providing nine years of continuity to the Ports Infrastructure. Â Among the many things Mark did, was maintaining and documenting the current portbuild system that the team uses for -exp runs and package building. Â With his other bugbuster@ hat on, he played middle man contacting maintainers of BROKEN and DEPRECATED ports.
On behalf of the Ports Management team, we would like to thank Mark for his many years of service and dedication, his contributions will be greatly missed.
Thomas
on behalf of portmgr@
Just to make it officially official, the ports feature freeze has been lifted.
Ports committers are now entitled to perform sweeping commits. Keep in mind that -exp runs are always a good idea if you think there is a significant change to the ports tree.
And just remember, PLEASE TRY TO NOT BREAK THE INDEX!
Thomas
on behalf of portmgr@
The FreeBSD Ports Management team is pleased to welcome Bernhard Froelich, aka decke@, to it’s ranks.
Bernhard was a long time ports contributor, and received his ports commit bit back in March 2010.
More recently, Bernhard was the one responsible for bringing us Redports.org shared tinderbox.
Please join me in welcoming decke@ to the team.
Thomas
on behalf of portmgr@
Pav Lucistnik, aka pav@, recently stepped down from his roll on the FreeBSDÂ Ports Management team.
Pav started on portmgr back in November 2006, he was the one responsible for many of the -exp runs over the years. His most dubious claim to fame was talking over the responsibility of krismails. We all looked forwward to our pavmails, right?
On behalf of the Ports Management team, we want to thank Pav for his years of  service, he will be missed.
Thomas
on behalf of portmgr@
FreeBSD 9.1 RC2 has been pulicly announced, it is now time for the the Ports Feature Freeze.
Normal upgrade, new ports, and changes that do not affect other ports will be allowed without prior approval, but with the extra
Feature safe: yes
tag in the commit message. Any commit that is sweeping, that is, touches a large number of ports, infrastructural changes, commits to ports with unusually high number of dependencies, and any other commit that requires the rebuilding of many packages will not be allowed without prior explicit approval from portmgr@.
Check out http://www.freebsd.org/portmgr/implementation.html#sweeping_changes for what constiutes a sweeping change.
Thomas
on behalf of portmgr@
It was recently posted on, http://blogs.freebsdish.org/portmgr/2012/09/01/change-to-the-header-in-ports-makefiles/ that we would adopt a new header for the ports Makefiles. The initial discussion seemed to show enough support for the idea of completely stripping the header, leaving only the $FreeBSD$ tag. After the announcement was made, more people stated strong feelings that when and where possible attribution be maintained in the header.
A private discussion was held among ports committers, and while opinions were as varied as the individuals who shared them, it was decided to unify on a two line header.
# Created by: J.Q. Public <[email protected]>
# $FreeBSD$
The Whom line from the classic six line header becomes Created By.
Sometimes, as a result of a repocopy, or changed maintainership, the Created By and MAINTAINER is no longer in synchronisation. To avoid confusion, the first line can be removed, optionally leaving us with a one line header.
# $FreeBSD$
Removing the line of attribution is to be done only at the consent/request of the original contributor.
As before, we ask this header only be updated in conjunction with a regular update, as we do not want any unnecessary churn to the repo prior to the pending Ports Feature Freeze.
Thomas
on behalf of portmgr@
The development of FreeBSD ports is done in Subversion nowadays. For the sake of compatibility a Subversion to CVS exporter is in place which has some limitations. For CVSup mirroring cvsup based on Ezm3 is used which breaks regularly especially on amd64 and with Clang and becomes more and more unmaintainable.
Read more at http://lists.freebsd.org/pipermail/freebsd-ports/2012-September/078099.html
An idea has been floating around for some time, and it was brought up again on the ports@ mailing list recently, please remove the extraneous header information from the Makefile, leaving only the $FreeBSD$ id on the first line.
It is an idea that is long overdue, so from now on, the other fives lines shall be removed.
We do request that this be done sparingly in the short term, as we do not want to cause any additional churn on the repo as we approach our upcoming Ports Feature Freeze, still tentatively scheduled for September 7.
So please proceed only on existing updates. Please do not do any sweeping commits until we have the ports tree stablised post 9.1 tagging. Also bear in mind that Redports/QAT queues a job for every change done to a Makefile, we do not want to overburden the QAT at this time. It is important to allow this service to run at peek efficiency at this time to ensure it’s full potential as we approach the upcoming Feature Freeze.
The new look of the Makefile has been document in the Porter’s Handbook.
The next item on the todo list is to update devel/newfile for those that do a port create.
Thomas
on behalf of portmgr@
I have been using pkgng on a few machines now and I'd like to share some thoughts about how it behaves in real-world situations. Overall, I'm very happy with it and it's immensely better than what we had before. There are some rough edges which need to be solved but those are mostly a property of the ports system itself rather than pkgng.
Florent Thoumie, aka flz@, recently stepped down from his roll on the FreeBSD Ports Management team.
Florent started on portmgr back in August 2008, being instrumental in maintaining the legacy pkg_* code plus other aspects of the ports infrastructure, including but not limited to the unifying of the code base for the ports build system.
On behalf of the Ports Management team, we want to thank Florent for his years of service, he will be missed.
Thomas
on behalf of portmgr@
FreeBSD (and BSDs in general) traditionally have source-based upgrades and installs which extends to the third party software collections - ports or pkgsrc and similar. This is all fine and offers unprecedended flexibility when tailoring system to specific needs, but sometimes this flexibility is less important than ease of use or time savings which can only be achieved with binary packages. Enter pkgng, the next-generation binary package management system by Baptiste Daroussin and others, which replaces the old-style ports and packages system.
The FreeBSD 9.1 schedule has been published, http://www.freebsd.org/releases/9.1R/schedule.html. Historically we have done a Feature Freeze at RC1, we are going to try do it with RC2 this time, tentatively scheduled for August 3, subject to schedule slippage.
At the time the the Release Engineering team announces RC2 is ready, we will then enforce “Feature Safe” commits only. This means no sweeping changes will be allowed, see http://www.freebsd.org/portmgr/implementation.html#sweeping_changes
Once portmgr@ is satisfied that the requisite packages are built to ship with FreeBSD 9.1, the ports tree will be re-opened for business.
Thomas
on behalf of portmgr
The FreeBSD ports tree will migrate from CVS to Subversion soon. The anticipated date for the migration is July 14th. This will have no impact for ports tree users as there will be a SVN to CVS exporter.
Please note that cvsup will still work after the migration. Nevertheless c(v)sup is pretty dated so you may want to see if portsnap(8) will fit your needs.
Beat and Thomas
on behalf of portmgr@
Hi Fans,
The FreeBSD Xorg Team is pleased to announce Xorg 7.7 Release. We are very happy to be able to Call for testing shortly after the Xorg team annouced 7.7 release. This CFT is also open for discussion on how we should move forward with xorg release as we are facing some issues and we would like to ask for your opinion. Right now we have 2 existing xorg versions in our Ports Tree. The situation is quite bad due to our poor graphic card support. That means we do not have much choice but to take it as how it is now. But with regards to mesa support, we have to face some new challanges.
With the new mesa 8.0 release, accelerated support for a number of older graphic cards was dropped. At the moment we are not sure how to deal with that.We are thinking of just replacing mesa 7.11 with 8.0 or making a new flag like WITH_MESA= 7.11.2 / 8.0 in combination with WITH_NEW_XORG, and let the mesa 7.6.1 set as default together with the old xorg version. Obviosly the latter option make the already complex situation more complex. The problem is, users, especially the new ones can easily get confused with it. Another issue is, the packages.We can’t deliver a package set with the new Xorg releases. This means users with new hardware will have to compile everything by themselves. Though I’m totally fine with compiling, not everyone has the CPU power to compile everything. What I’m trying to say is, I would love to see the newer xorg released as the default version, but i know this will break a lot of old hardware. The thing is, when we want to try to become a Modern Operating System, I dont see any other way to make the new xorg as default but to give Users the chance to compile the old xorg with a flag like WITH_OLD_XORG.
Some notes regarding KMS support:
KMS Support has been completely migrated to FreeBSD 10. The MFC to 9 will come soon, that means so long its not MFC’d to 9-Stable, users need to get the latest patch from our x11 mailing list.
This testing includes
* libdrm 2.4.34 (including KMS support)
* mesa 8.0.3
* full Xorg 7.7 release
Checkout Xorg Development Repo:
You will need to install devel/subversion in order to checkout the xorg repo. Next, you will need to add WITH_NEW_XORG=yes in your /etc/make.conf if you want to try out the new Xorg and mesa. Note
that if you are not qualified for the KMS patch, you shouldn’t use WITH_NEW_XORG=yes because the old intel driver doesn’t build with the new X server. If you are qualified, you should also set WITH_KMS=yes
in /etc/make.conf. Nvidia and ATI users should set WITH_NEW_XORG=yes.
svn co https://trillian.chruetertee.ch/svn/ports/trunk
A small merge script to merge the svn checkout into the real portstree can be found here:
http://people.freebsd.org/~miwi/xorg/xorgmerge
The script is a modified version of the old kdemerge script. Please set the KDEDIR variable to the path of your X.org ports. After merging, run one of the following command, depending on which
tool you use to manage your installed packages.
portupgrade -af \*
portmaster -a
After installing these, you will have to rebuild all xf86-* ports. We will bump all releated ports during the commit to the ports tree.
Roadmap:
Our current plan is to let the CFT running for a while, and see what the outcome of the discussion above is. We hope to get a lot of feedback to solve as many problems as possible. Also we are working on the
libglut to freeglut migration, this will definitely complete before we import Xorg 7.7. So we still have enough time. We are looking forward for your feedback.
- miwi on behalf of the FreeBSD X11 Team
The new options framework has been committed one week ago, I would have expecting things to have been smoother but lots of fixes has been needed to have it correctly working.
In one week everything at least every major issues reported has been fixed, and now everything is working again as expected (if not please report it to me asap so I can fix it)
So from a maintainer point of view what does it brings:
From a port developer point of view:
From a user perspective:
How to enable/disable an options? simple in make.conf:
OPTIONS_SET= BLA # enable BLA for the whole ports tree
OPTIONS_UNSET= BLA # disable BLA for the whole ports tree
foo_SET= BLA # enable BLA just for foo
foo_UNSET= BLA # diable BLA just for foo
the user settings have an order or priority:
Note that you can disable this automatic make config by adding NO_DIALOG to your /etc/make.conf.
All of this means that ports-mgmt/portconf is not needed anymore for a centalisation of your configurations.
Short term goal: to avoid having the ports tree infrastructure keeping for ever old code like it was the case in the past for other manjor improvements, please update your ports to the newoption framework as soon as possible.
Long term goal:
The options framework was an important step in the cleanup of the ports infrastructure, next step in my concern will be to provide stage directory support aka: a ports will install everything in a stage directory and sync the files following the plist to the system or directly create the package out of this stage directory. Every sane package building system are using that kind of thing but the FreeBSD ports this is necessary as it also open the way to tons of new possibilities. Stay tune, this is coming soon!
Seems I forgot to announce that the linux_base-c6 is in the Ports Collection now. Well, it is not a replacement for the current default linux base, the linuxulator infrastructure ports are missing and we need to check if the kernel supports enough of 2.6.18 that nothing breaks.
TODO:
To my knowledge, nobody is working on anything of this. Anyone is welcome to have a look and provide patches.
For some time now, I have been maintaining pretty much alone the LibreOffice port for FreeBSD, trying to provide all the features LibrOffice has to our users.
I managed to port the 3.3.x series of LibreOffice to FreeBSD some time ago and tried to keep updating it as fast as possible as soon as new releases were out.
At the beginning I was thinking about maintaining 2 concurrent of LibreOffice at the same time: legacy and "normal" to reflect the upstream support. But this take too much time, I'll kill libreoffice-legacy in the next weeks.
The problem is that it is really time consuming, not that it is really complex, the LibreOffice upstream is really nice and really responsive, other maintainers from the BSD community, has also been really helpful.
Some time ago, I decided to create office@ to help maintaining every office related ports maintained on FreeBSD, it worked quite well, sunpoet@ taking good care for examples of the different hunspell/hyphen/mythes dictionnaries/thesaurus, pfg and maho taking care of Apache OpenOffice and all of us working on the third party libraries/fonts/etc needed by all those big office project.
But I'm still missing help on LibreOffice itself, I just committed 3.5.2 some days ago, and 3.5.3 is almost there.
We also still have known issues on 3.5.2:
All the libreoffice work is done on redports svn
if you have an account and are willing to help tell me so that you can have access to the office svn on redports.