Xorg 7.2 has almost been committed to the FreeBSD ports tree. “Within the next 24 hours, the long-awaited update to the X.org 7.2 windowing system will be committed to the ports tree. This upgrade has been 6 months in the making and would not have been possible without the dedicated work of Florent Thoumie, Dejan Lesjak and many others in our army of developers.”
This is great news. I can get rid of my git tree soon. There seem to be a few warts in the upgrade process, but there’s little point in continuing to maintain a total freeze.
The DAG port* and pkg*-tools must walk for dependency and conflict checking has now grown by SEVERAL entries; watching portupgrade -N gnome2 listing the dependency “dots” is now almost comical.
Sadly, it also means that the “registering package install” phase is taking *ages*, because walking the /var/db/pkg directory to check for conflicts must naturally look into every x*, lib* and font* directory, and, with Xorg 7.2, those are pretty numerous.
There have been discussions about overhauling the installed ports and packages metadata backend, but most devs are frowning upon the idea of using SQLite (because of SQL) or relying entirely on BDB (because BDB breaks, period); actually, relying on single-file DBs is frowned upon because corruption that would otherwise only affect a single file on the /v/d/pkg tree will now blow the whole thing, and fully transactional DBs are too heavyweight for the purpose of storing this kind of information.
Well, files are not working very well either, at least not the way they’re currently been parsed.
Some people proposed using a lightweight DB as a cache, and the /v/d/pkg filesystem tree as fallback to rebuild the DB in case of corruption. Despite obvious redundancy of information, and hence the necessity of keeping both sets of data in sync, that’s the approach I liked the most.
Edit: newsflash! /me making grammar mistakes!
Edited 2007-05-19 19:29
It’s amazing to me that people think that by just sticking everything in a binary blob that it’ll just magically make everything blazing fast. The reason the port commiters don’t want to use SQLite or BDB is because it has nothing to do with the problem.
The problem has nothing to do with the database format and has everything to do with inefficient algorithms for sorting large dependency graphs and the use of recursive calls to make.
Both of these problems have been addresses and are waiting to be commited to CVS. These should result in a 30 fold decrease in package registration time all without messing with the pkgdb structure.
http://www.freebsd.org/cgi/query-pr.cgi?pr=112630
http://www.freebsd.org/cgi/query-pr.cgi?pr=112765
>Sadly, it also means that the “registering package install” phase is taking *ages*, because walking the
Somewhat an exaggeration, maybe at a PIII800.
People don’t sleep, there is already a solution in test to speedup it.
http://blogs.freebsdish.org/netchild/2007/05/17/speeding-up-the-pac…
Dude, I’m not that thick to report on something like that when I haven’t experienced it myself.
Selected DMESG snips:
CPU: AMD Sempron(tm) Processor 3000+ (1680.01-MHz 686-class CPU)
Origin = “AuthenticAMD” Id = 0x40ff2 Stepping = 2
Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR ,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
Features2=0x2001<SSE3,CX16>
AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!& gt;
AMD Features2=0x19<LAHF,ExtAPIC,CR8>
real memory = 535691264 (510 MB)
ad0: 58644MB <Maxtor 6Y060L0 YAR41VW0> at ata0-master UDMA133
Not top notch, but no slouch either.
ls /var/db/pkg/ | wc -l
583
Considering that
ls /var/db/pkg/ | egrep -i -e “^x” -e “^lib” -e “^font” | wc -l
284
is probably a fair approximation of what the xorg 7.2 metaport installs, and considering that I’m still not done installing Gnome 2, I wouldn’t consider this to be an overcrowded system. Not by a *long* margin.
Registering any packages that have direct or indirect dependencies on xorg is taking in excess of 2 minutes here.
Anyway, MANY thanks to those who pasted those links to patches that greatly mitigate those speed problems. Beats the “ancient hardware” red herring anytime.
Edit: “considering” word was missing
Edited 2007-05-19 23:26 UTC
Hm… Sorry. Just noticed you were among the people who posted links related to speeding up port*/pkg*.
Anyway, please, don’t you ever use that “old P3-800” argument ever again, please, pretty please?
Please?
Edit: osnews v4 not handling quote closure correctly…
Edited 2007-05-19 23:59 UTC
Sadly, it also means that the “registering package install” phase is taking *ages*, because walking the /var/db/pkg directory to check for conflicts must naturally look into every x*, lib* and font* directory, and, with Xorg 7.2, those are pretty numerous.
There are PRs now to address the slow registering of ports. Threads on the ports mailing list show the reduction going from several minnutes to under 10 seconds.
Would have been nice if these were available before 7.2 hit the tree, but at least they are available. And they should hit the tree soon.
Yeah, been waiting all week for that commit. Time to rebuild the laptop and get her up to 6.2-STABLE
Kudos to all the FreeBSD devs!!!!
that means also a improvemnt for PC-BSD! yay!
Ladies and gentlemen, please start your engines :o)
http://lists.freebsd.org/pipermail/freebsd-ports/2007-May/041029.ht…
“As you may already know, the X11 team has been working hard for the past few months to upgrade X.org ports to 7.2. After a couple of weeks of testing, we’ve finally committed this upgrade. We also decided to make the PREFIX merge at the same time (moving X11BASE into LOCALBASE), which explains why there are thousands of ports affected by this commit.”
“We also decided to make the PREFIX merge at the same time (moving X11BASE into LOCALBASE), which explains why there are thousands of ports affected by this commit.”
This is what I’ve waited for. Now every program not belonging to the OS itself is installed in /usr/local, No more searching both /usr/local and /usr/X11R6.
The new Xorg will be interesting in upcoming FreeBSD based live file systems in order to autodetect GPU ‘n stuff.
Congratulations, great work! Time to reinstall on some boxes. 🙂
This is wicked, I can’t wait
I upgraded yesterday and it went fine. I haven’t had a problem and might even try beryl later next week.
No wonder cvsup was very slow on only a few updates yesterday. Right now cvsup is running at normal speed and I see just about every port coming by so I’ll be doing my upgrade soon.
I hope it’ll be as smooth as yuors. *crosses fingers and toes*
just upgrading ports and doing a make-install in /usr/ports/x11/xorg will not work
/usr/ports/graphics/dri is broken
the upgrade instructions
http://wiki.freebsd.org/ModularXorg
are well documented but look like a major headache for most mortals
i had planned on reinstalling for freebsd7, it looks like i’ll just wait for this upgrade to make it in to a fresh release…whats the rush? its not like my monitor is going to start dancing when 7.2 is installed
anyone who knows if “make install” will ever do the trick, please comment
Read /usr/ports/UPDATING for the procedures to use.
Good habit to get into is reading /usr/ports/UPDATING after every ports tree update. That’s what it’s there for.
yes i am doing that now! thanks for the advice
seems to be going okay
I’m so impressed by the huge work being done by small group of devs.
You amazed me, thank you for the hard work guys!
Sorry if this is a stupid question (I’m a Linux guy…) Does this upgrade mean that Compiz & Beryl will be supported on FreeBSD out of the box?
Both are in the ports tree right now under x11-wm, so I’d say they’re supported out of the box.
I’m waiting for the complete portupgrade to finish and if all goes well, maybe I’ll try them both.
Note to KDE users; the Compiz port by default disables KDE support, Beryl has no mention of KDE in the makefile.
Too bad because I use KDE, now I can only try Beryl, not feeling like experimenting too much on this laptop.
I don’t know about Compiz but I guess it’s almost the same as Beryl (except it’s in one port). Beryl/Aquamarine hasn’t been ported yet cause I don’t use KDE and the new maintainer doesn’t seem to be using it either.
Anyway, Aquamarine only serves one purpose AFAIK, handling KDE windows decoration themes, so you can perfectly run Beryl with Emerald (Beryl window decorator) and KDE.
Beryl and/or compiz will only work properly on nvidia cards. Xorg 7.2 on FreeBSD does not properly support AIGLX on either radeon or intel hardware. On intel cards, AIGLX will cause the machine to lockup when you stop X, and on radeon cards, AIGLX will cause the machine to lockup when starting X.
And, last I heard, even with nvidia cards you need to downgrade to an older version of the xrandr libraries than are available in the ports tree.
Adam
I’m just waiting on wpi (Intel 3945 a/b/g) to be merged, which will make FreeBSD a definite contender for my laptop
With that being said, is there any eta on FreeBSd 7.0 and have they added the required features which Nvidia listed on the mailing list? I haven’t found a ‘progress report’ in that regard.
If you really need aquamarine why not port it over yourself.
update ports tree – portsnap (GIT is gone)
update system sources – csup
install/update applications – portmaster
Now all I need is for GNUstep to get updated and put into the ports tree.
had to add a wm to /usr/local/lib/X11/xinit/xinitrc
(commenting out twm)
after adding /x11/xinit and some other stuff
my old ‘starx …’ or whatever either retried X11R6’s X(org) or ran twm otherwise, without running the following,
discovered by much trial and error (pkg_deleted -f /var/db/pkg/xorg (6.9 lots of, before installing xorg)
***********************************************************
#xinit /usr/local/lib/X11/xinit/xinitrc — /usr/local/lib/Xorg
*********************************************************
^^^^ reason for this post, btw))
********************************************************
however I consider on this box the Xorg upgrade ‘done’ (I unfortunately for various reasons do not use portupgrade nor any other recc’d tool) and just the ports to bump. I expect to complete the UPDATING instructions smoothly, however taking several months (as I don’t have a lot of time to do it all at once)
Edited 2007-05-21 00:47
Now if only adobe and flash would play nice i could wipe debian off this desktop heap and let it play nice with the rest of my systems. My 3 other systems, a file server a sandbox and an old mac g4, are constantly singing “one of these things is not like the other” with a huge grin. I wouldn’t care if I wasn’t doing web-dev part time.
I try to preview a group collaberation project with flash in it and BOOM seg fault. I got sick of kicking my wife of her mac so I could see what I was doing.
Sorry, off topic, I know. But it’s so frustrating! And in no way Freebsd’s fault. Sorry if it sounded like I was trolling, Im just mad at Adobe.
Thanks to all the devs and testers for working so hard on this thankless job. I have upgraded two boxes and did a clean 6.2 + Xorg 7.2 on another and I have not had any problems whatsoevr. FreeBSD just rocks.
Thanks to all the devs and testers for working so hard on this thankless job.
Hmm, for some reason I found this really amusing.
Heh, yeah, I guess what I mean is that they don’t get enough props. It was a big job.