I’ve been talking to Kris yesterday since the ports are almost ready, and he asked me to send him a tarball of the tree. After some INDEX commits fixes, I sent him one. Not sure when he will start building it on pointyhat since he’s currently travelling (everybody has the right to take some days off) but he’s been sending emails about non X11BASE-clean ports on ports, so I guess he just likes being busy 
I’m almost right on time, since I said I’d have everything ready to start builds in december. I guess X.org is waiting for Mesa 6.5.2 to release a new xorg-server release (and then 7.2). I’m now working on an upgrade path. Hopefully it will be in the wiki page by tomorrow.
Edit: I just added the upgrade commands to the wiki.
As I said, I upgraded the beryl/emerald ports to 0.1.2 and pushed them to the shared git repository. It builds/packages fine but I actually haven’t run-tested them yet. This will have to wait a couple of hours again. I hope to get as many bugs reports (or better success reports) for beryl as I got for xorg, so test test test!
Rene Ladan has reported that libxcb is still broken on CURRENT. Will try to fix it this week end.
Edit: It has been reported that it works fine with nvidia beta driver 9629.
i just pushed my local changes. Not much to say. There are still a few packing list issues with fonts. I’ll investigate this week end. Starting in 5 minutes, I’ll work on updating my beryl ports to 0.1.2 and create the missings ones.
Have a look at the x11@ archives for more information.
I’ve been quite lazy since I came back from EuroBSDCon. Things were in pretty bad shape when I left for Milan. The latest update of libX11 depended on libxcb which had a broken dependency on pthreads. Most xf86-input ports were broken after the latest inputproto update. I couldn’t build latest xorg-server because it required a Mesa HEAD snapshot. Some ports got outdated, some others lacked a PORTEPOCH bump, some were still categorized in x11 though they moved to x11-fonts, ...
Well, that’s what you get when you try experimental stuff. Anyway I’ve fixed most of those issues, so that anything in the git tree should be alright (except xf86-input ports besides mouse/keyboard/evdev). If you’re on IRC, you probably already know that I won’t be maintaining those ports once they reach the original ports tree. Since it’s becoming a burden to make sure all pieces fit together and stuff, I’ve also decided that I would stop updating ports after X.org 7.2 will be released (hopefully in 3 days). Once all the ports are up-to-date, I’ll focus on fixing bugs in those ports and making sure (with Kris probably) that the merge doesn’t break too much things.
I’m getting really bored with all this X.org porting work but I’ll try to deliver beryl ports at the same time so that people can benefit from their new xserver as soon as possible. Ports are still at 0.1.1 but updating to 0.1.2 shouldn’t be too hard (there are a few new ports to create). Stay tuned.
Well this second version doesn’t add much to the first one but it’s worth an update. First the command is now called “include” rather than “#include”, and you don’t need the chevrons anymore. Just put pfctl.cpp in /sbin, chmod it 755 and set pf_program to /sbin/pfctl.cpp in /etc/rc.conf.
This is particularly useful when you have servers having each a different a subset of services. You can have a common package to install all sub-rulesets in /etc/pf.conf.d/ and select only the ones you need. Imagine you have srv1 with www/pop3 and srv2 with mysql/imap. Create a /etc/pf.conf.d/ and populate it with some files (say rules.www, rules.pop3, rules.imap, rules.mysql). Basically, you’ll have in srv1’s pf.conf something like:
# basic definitions
include rules.www
include rules.pop3
and in srv2’s /etc/pf.conf:
# basic definitions
include rules.mysql
include rules.imap
If you’re using comments in /etc/pf.conf.d/ files, you’ll have to use comments that cpp understands (ie. not starting with ‘#’).
If you’re using this trick, I’d be happy to hear about you. If you have a less hack-ish solution to do the same thing, I’d also be happy to read about it
Might be the first one to blog about that.
We’re in unimi.it according to the wireless networks i can see. That’s somewhere in Milan (no idea where it is actually). Dario has been kind enough to pick Max and myself at the hotel and bring us here.
Wireless is up and running and the next step will probably be to eat something.
Yesterday (or was it two days ago?), I was looking for a way to include a sub-ruleset in pf.conf from a different file and noticed that it wasn’t possible without a patch. I asked dhartmei (Daniel Hartmeier, the main developer of pf) if there was a chance to see it committed upstream (read: in the OpenBSD source tree). He answered that some people strongly disagreed with this patch, so I thought I would try to convince mlaier (Max Laier, pf maintainer for FreeBSD) to maintain the patch in our tree. He wasn’t too happy with the patch either, stating that the parser was already complicated enough as it is but told me I could probably use ‘pfctl -f -’ to do what I want. How did I miss that?
So I’m thinking of something like this in /etc/rc.conf:
pf_program="/usr/bin/cpp -P -x c -I/etc -E /etc/pf.conf 2>/dev/null | /sbin/pfctl"
pf_rules="-"
This way I can use #include “foo.conf” in my pf.conf file \o/. Admittedly, this is hackish to say the least, and it won’t work if your /usr partition is a
NFS, but still, this should be working, and you can even use #define if pf macros ain’t good enough for you
Edit: This actually doesn’t work, just add ‘eval’ in front of all $pf_program invocations in /etc/rc.d/pf. You can actually set pf_program to a shell script that calls cpp to avoid the mod in the rc script.
Edit2: < @Mavvie> that’s the worst usage for the C preprocessor I’ve seen in my life.
Edit3: As I said in Edit 1, you can use a script like this, and set pf_program to its path.
Edit4: Updated script discussed here.
After 3 days of fight with xorg-server, mesa, dri and beryl, I’ve finally managed to make it work on my Dell Latitude D620 (with Intel i945GM). Here is the screenshot. Agreed, there’s not much to see, and the screenshot isn’t the nicest one you have seen. The laptop is running -CURRENT with all the debugging features (WITNESS and stuff) so I’m hoping it has a substantial impact on performance because beryl isn’t so smooth. But hey, that’s only a cheap intel chipset, so I can’t really complain.
I haven’t had so much luck with nvidia driver (beta driver, the one in ports don’t have GLX_EXT_texture_from_pixmap), beryl crashes somewhere in libGLcore.so.1. That said, I noticed yesterday that xorg-server was built against Mesa 6.5 (instead of 6.5.1). I think it doesn’t matter since I use LD_PRELOAD=/usr/local/lib/libGL.so.1 (being nvidia libGL) but I’ll rebuild xorg-server against Mesa 6.5.1, just to be sure.
Most of the ports are written, but they’re still not in the git repository because of missing bits (imake/makedepend from freedesktop) and lack of polishing but I hope to commit them by the end of the week, so you reader (if any) can test them.
People have been complaining about problems to clone/fetch/pull the repo from time to time (or everytime for the least lucky). We’ll probably set up a git mirror soon. Anyway, with 6.2-RELEASE, the bge(4) bugs preventing me to use git-daemon should be gone.
Recent Comments