[ HEADS UP ] Ports unstable for the next 10 days

&quot said:
Hi,


As announced before, a few big commits, that touch some thousands ports
are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7
April.

The first one was done, update of graphics/png (including a shared lib
version bump), with about 5000 ports affected.

We do _NOT_ recommend updating ports until this commits are all done,
and the problems are fixed, except if you want to help testing / fixing.

Before reporting failures, please take a look at ports@ list, and
http://qat.tecnik93.com/index.php?action=failed_buildports&sort=last_built
to find out if the problem hasn't already been reported or even fixed.
We also have two incremental builds on Pointy to catch the problems.


Thank you,

With hat: portmgr@

From freebsd-ports@, i thought i should spread the word.
 
Thanks for the info. Maybe that could be
useful as an addendum to the latest UPDATING
entry about png also... would be appreciated
I surmise by those reading UPDATING and not
this forum.
 
The directions for updating via portmaster are currently incorrect in UPDATING -- they should be:

Code:
portmaster -r 'png-*'

I've already informed dinoex@ about this.
 
But you should really wait for a few days, especially when using X.

E.g. parts of XFCE became available over the course of two days, with Thunar (a dependency for lots of XFCE modules and related programs) appearing last. This could happen on any WM/DM, leaving you in limbo until the 'lowest dependency' finally shows up.

So wait until the onslaught of port updates (especially the PNG version bumps) dries up before attempting upgrades.

With the X.org upgrade in the pipeline as well, it's probably best to wait until at least April 10, and then apply the directions in /usr/ports/UPDATING in order before proceeding (chances are you'll recompile large parts of the X system several times over if you don't).
 
And idea...

I was wondering if maybe similar port bumps
(jpeg, png, xorg-server, gnome...)
could be
a... classified (greater than 300? ports affected)
then once- or twice- yearly
all of them rolled out in a two-week (?)
"wait on updates" ports-caution "not -- a -- freeze"
(like this one). Thus persons with a
sizable number of ports installed can delay
usual rebuild procedures and
plan a larger one. Seems like an easy
"feature" with which to upgrade the
ports system.
 
Code:
Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found.
Updating from Sat Mar 27 08:39:39 CDT 2010 to Mon Mar 29 12:21:46 CDT 2010.
Fetching 4398 patches.

yikes!!

Code:
pkg_version -v
apache-1.3.42                       =   up-to-date with port
autoconf-2.62                       =   up-to-date with port
autoconf-wrapper-20071109           =   up-to-date with port
bash-4.0.35                         =   up-to-date with port
bison-2.4.1,1                       =   up-to-date with port
cclient-2007e,1                     =   up-to-date with port
dovecot-1.2.10                      =   up-to-date with port
expat-2.0.1_1                       =   up-to-date with port
gettext-0.17_1                      =   up-to-date with port
gmake-3.81_3                        =   up-to-date with port
help2man-1.37.1_2                   =   up-to-date with port
libiconv-1.13.1_1                   =   up-to-date with port
libsigsegv-2.5                      =   up-to-date with port
libtool-2.2.6b                      =   up-to-date with port
libxml2-2.7.6_2                     =   up-to-date with port
m4-1.4.14,1                         =   up-to-date with port
p5-gettext-1.05_2                   =   up-to-date with port
pcre-8.00                           =   up-to-date with port
perl-5.8.9_3                        =   up-to-date with port
php5-5.2.12                         =   up-to-date with port
php5-imap-5.2.12                    =   up-to-date with port
php5-mbstring-5.2.12                =   up-to-date with port
php5-pcre-5.2.12                    =   up-to-date with port
php5-pgsql-5.2.12                   =   up-to-date with port
php5-session-5.2.12                 =   up-to-date with port
php5-simplexml-5.2.12               =   up-to-date with port
php5-spl-5.2.12                     =   up-to-date with port
php5-xml-5.2.12                     =   up-to-date with port
php5-xmlrpc-5.2.12                  =   up-to-date with port
phppgadmin-4.2.2                    =   up-to-date with port
pkg-config-0.23_1                   =   up-to-date with port
portaudit-0.5.14                    =   up-to-date with port
portmanager-0.4.1_9                 =   up-to-date with port
portmaster-2.19                     <   needs updating (port has 2.20)
postfix-2.7.0,1                     =   up-to-date with port
postfixadmin-2.3_1                  =   up-to-date with port
postgresql-client-8.4.3_1           =   up-to-date with port
postgresql-server-8.4.3_1           =   up-to-date with port
screen-4.0.3_7                      =   up-to-date with port

w00t! Only one thing to update.

:e
 
DutchDaemon said:
But you should really wait for a few days, especially when using X.

I "burned" myself once ): but my question is about KDE 4.4.? which is coming to the ports tree soon. Is it better for update png before KDE 4.4.? or wait for it came out, please?

Thanks.
 
Haha, whoops, I guess I should have read this before I went and # portupgrade -uvfr png\* pkg-config\*. Oh f'well. Guess I get to do it all over again next week.
 
You should be alright on the libpng front. I think that storm has passed by now. But yeah, anything even remotely belonging to X11, Gnome or KDE (including stuff using any of its libraries or helper apps) should be left untouched for at least two weeks.
 
fronclynne said:
Haha, whoops, I guess I should have read this before I went and # portupgrade -uvfr png\* pkg-config\*. Oh f'well. Guess I get to do it all over again next week.

After few hours reading this I checked my /usr/ports/UPDATING and happily ran # portupgrade -fr graphics/png. By the time I realized it was(still is) upgrading OOo. OOohhh my..

Wonder if it's my age or my fast fingers..
 
go /usr/lib/libbegemot.so or go $HOME

sixtydoses said:
(still is) upgrading OOo. OOohhh my..

Yes, they're not joking about the 12G of build space (and the CPU stress). I like to -x openoffice\*, but when an underlying library version jump, like this libpng.so.5 -> libpng.so.6 happens, you either go all in or you don't go at all.
 
Does anyone perhaps have an old snapshot (preferably 2-3 days old) before the ports went unstable? I just happened to be needing to install FreeBSD on a box during this time of peril, and I really do not want to use a very outdated snapshot (which is all I have). That would be great if someone could upload it and email me a link.

Thanks in advance,
Brandon Falk
 
falkman said:
Does anyone perhaps have an old snapshot (preferably 2-3 days old) before the ports went unstable? I just happened to be needing to install FreeBSD on a box during this time of peril, and I really do not want to use a very outdated snapshot (which is all I have). That would be great if someone could upload it and email me a link.

You may have a look at http://pub.allbsd.org/FreeBSD-snapshots/.
 
You can use csup(1) to get a ports tree of an older date (use the 'date' tag in the cvsupfile), though it remains to be seen whether the older tarballs associated with these ports are all still there. Should generally be fine with a ports tree of, say, a week ago.
 
DutchDaemon said:
You should be alright on the libpng front. I think that storm has passed by now.

I was a bit overconfident here. I saw a couple of dozen new png-based port bumps in the past day. So you may still have to re-do all of it.

So again: wait at least two weeks before attempting massive recursive port upgrades related to png, x11, curl and kde.
 
RE: the above "needs build space", one can
set WRKDIRPREFIX to build on a /mnt and
not run out of space in, say, /usr during
building of many ports at once...
Code:
pkg_delete -f /var/db/pkg/[something] && make build  WRKDIRPREFIX=/mnt && yell
(assuming one has another disk mounted on /mnt), which
I initially neglected to post.
 
jb_fvwm2 said:
RE: the above "needs build space", one can
set WRKDIRPREFIX to build on a /mnt and
not run out of space in, say, /usr during
building of many ports at once...
Code:
pkg_delete -f /var/db/pkg/[something] && make build  WRKDIRPREFIX=/mnt && yell

I've thought about using tmpfs(5) (or in a pinch mdmfs(8)) to speed up the builds (and I also don't have to worry about that occasional stray $WRKDIRPREFIX/*/*/work/ hanging around when something goes awry), but 11 or 12 G is a bit much with only 4G of RAM.
 
If you want to compile all OOO packages you need ~60GB :D [just making silly note]

I can only suggest using ccache when building OOO monstrosity. It helps A LOT
you can disable atime, on bough zfs and ufs.
On zfs I also disable checksums, to speed things up on partition that I created to build OOO packages.

4G ram is good, but if any of you want to build OOO with 2G ram or 2.5G ram with zfs (like me) I suggest adding swap [just in case you don't have few spare bits in ram]
 
I have been doing maintenance as normal, noticed php5 got touched but not much else.

curl got an update but is still out of date along with dozes of other ports out of date.

nothing is actually broken tho.
 
Oh, mine is broken, thunar just crashed if I click on a directory that contains png file in it lol.


Anyway, quoting Ion-Mihai Tetcu:

Just a status update:
PNG and cURL are in, and png fall-outs are believed to be fixed.

Xorg update has gone through an -exp run on Pointy and our xorg team is
working on fixing the approx. 60 ports with problems.

I will begin -exp runs for Gnome and KDE updates tonight or tomorrow
morning.


Packages status:
- i386:
- 6 after png and curl
- 7 after png and curl
- an 8 incremental build is in progress and should be shortly finished
- 9 pacakges are from middle March
- amd64:
- 6 packages are post png and curl
- 7 build is in progress and will be finished tomorrow
- 8 last build was done in the middle of the png update/fixes; we
won't run an other before Xorg, KDE and Gnome go in (for lack of
resources).
- 9 build in progress (with sources that are believed to fix the zlib
problem).


In other words, if you wish to update without waiting for Xorg, Gnome
and KDE now it's a good moment.
 
tried to update mplayer to mplayer-0.99.11_17 and have got the following (don't know if this bug related to this "thread announcement":
Code:
...
cc -O2 -pipe -O3 -ffast-math -fomit-frame-pointer -fno-strict-aliasing -I./libavcodec -I./libavformat -Wdisabled-optimization -Wno-pointer-sign 
-Wdeclaration-after-statement -I. -I. -I./libavutil -O2 -pipe -O3 -ffast-math -fomit-frame-pointer -fno-strict-aliasing  -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/local/include/freetype2 -I.. -I../libavutil -I/usr/local/include -I/usr
/local/include  -I/usr/local/include/freetype2 -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-
2.0/include -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 -I/usr/local/include -I/usr/local/include
/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2   -I../libavcodec -I../libavformat 
-Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -I. -I.. -I../libavutil -O2 -pipe -O3 -ffast-math -fomit-frame-pointer 
-fno-strict-aliasing  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/local/include/freetype2 -I... 
-I.../libavutil -I/usr/local/include -I/usr/local/include  -I/usr/local/include/freetype2 -I/usr/local/include -D_THREAD_SAFE -I/usr/local
/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pango-1.0 -I/usr
/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2     
-c -o dvb_tune.o dvb_tune.c
dvb_tune.c:33:19: error: error.h: No such file or directory
gmake[1]: *** [dvb_tune.o] Error 1
gmake[1]: Leaving directory `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/stream'
gmake: *** [stream/stream.a] Error 2
*** Error code 1

Stop in /usr/ports/multimedia/mplayer.
*** Error code 1

Stop in /usr/ports/multimedia/mplayer.
maybe someone will point me in right direction?
 
varnie said:
tried to update mplayer to mplayer-0.99.11_17 and have got the following (don't know if this bug related to this "thread announcement":
Code:
... -c -o dvb_tune.o dvb_tune.c
dvb_tune.c:33:19: error: error.h: No such file or directory
gmake[1]: *** [dvb_tune.o] Error 1
gmake[1]: Leaving directory `/usr/ports/multimedia/mplayer/work/MPlayer-1.0rc2/stream'
...
maybe someone will point me in right direction?

well as a hotfix just comment out the error.h in dvb_tune.c
line 33.

please file a problem report so the port maintainer can fix
this in a more correct way...

cu,
alice23
 
Idea - why not have a categorization in the ports system that specifies stable/new? The system would have a setting (like an RC entry or something) to specify what port release you want to grab when doing a portsnap.

That way, people like myself who want to keep a production server as updated as possible won't run the risk of not seeing a message such as this one before upgrading because the new ports could be released in the new category. Once everything has been hammered out as much as possible (say running at least a week without trouble), the new versions could be classified as stable.

Just an idea, but I think it'd be excellent for all but the simplest/most severe bug fixes.
 
Back
Top