Blog moves...
Okay, until dsd_ have time to update the feeds, I'd like to point the Gentoo/*BSD and multimedia updates followers that my new blog is at http://farragut.flameeyes.is-a-geek.org/ , that is my main Gentoo/FreeBSD box. It's going to be a stability test, too.
Now, waiting for it :P
Fighting the PAM bugs
So, even tonight I wasn't able to sleep. And this is bad. I had to sleep in the afternoon, that is even worse. But not like I can do much about that right now. I have to say I haven't even _eaten_ today. Sigh.
I spent the night fixing a few things here and there for Gentoo/FreeBSD, looking at what has to be done and stuff like that.. oh, thanks to Jeffrey, now the new stage is on the mirrors, I'll also look forward for providing an update VMX possibly.
But what I started doing this morning was a masochistic decision most likely. I tried fixing PAM bugs, starting from the infamous PAM 0.99 bump.
Well I have to say the build system is drastically improved since last time I tried (especially since it was completely broken that time), although there are still a few issues to solve.
I decided that this time we won't be applying a full load of RedHat patches to add this and that, I'd rather see more ebuilds for things like pam_console that are needed by utopia for instance.
Big fat warning: sys-libs/pam-0.99.* at this point in time is not supported as stable nor ~arch. It _will_ break your system most likely. vixie-cron stopped working for me until I rebuilt pam a second time for instance. There are less modules, as there are less patches. Everything still using pam_stack.so is going to break as we don't (and probably won't) ship that any further.
That said, I can use some test on this. I know that the userdb module links to libdb1.so in /usr, I'm going to move that out on its own ebuild actually, it's pretty obnoxious as it is now. I'll do that in the next days. I won't revbump it every time or we'll end up having a -r300 sooner or later, so you'll have to take a look at the ChangeLog or to my CIA stats page.
Also, I was able to nail down the list of PAM related bugs to 20, of which 11 are requests for new packages and 2 are version bump. Not bad at all for a mostly 1-man team. But of course I _do_ need some help. Also because most of those 11 new packages are interesting, but I can't manage all of them by myself.
I've also committed another --as-needed fix. I'm considering dropping -hashvals and -Bdirect in favour of using 2.16.92 binutils, as that should allow me to use --as-needed with wxGTK (and thus to write a check for ld version so that I can filter those only on older versions). I still have to decide on that. Update: I started wondering a bit, and I checked, binutils 2.16.92 already have support for -Bdirect, while the hashvals patch still applies, so I'll go with that now :) Update 2: more coffee, thanks, -Bdirect is not supported, I just checked the wrong binutils-config...
Ah, at the end, I ordered the two books from Amazon, €60 and shipping the first week of june... quite an ass of shipping but well, I can't find anything better. I hope at least that the work I'm going to do will compensate these costs. I was hoping also to use the $5 gift certificate that I got some time ago for answering an IBM's survey.. too bad it only works on the American Amazon.com and not to .co.uk, of course using that is no-go for me, too high the costs, would be paying more than $5 for the shipping :)
Finally xine-lib is fixed!
Okay, third blog entry in less than a day, but this is worth a small note.
Do anybody remember that xine-lib makes amaroK and any other frontend crash when trying to play/access an mp3 file when mad is not enabled?
Well, this behaviour is gone. xine-lib will just refuse to play it.
How did I fix that? Well with a big help from Ian Monroe of the amaroK team who gave me the backtrace to work on. Now is really fixed, yeeeee! :)
Again many thanks to Ian, and now I can be happy for today.
Update: seems like today is really xine-lib's day. Another big thanks then, this time to Mark Kretschmann, also from amaroK team ;) He reported to me (some time ago actually) that xine-lib wasn't playing authenticated HTTP streams, and helped nailing down the problem, today I had time to try the patch and it does really work now, xine-lib-1.1.2_pre20060328-r1 plays authenticated HTTP streams just fine.
If you can't sleep... bump!
Okay, so tonight I wasn't able to sleep. It's been a while my sleep was intermittent, and tonight was a "no" night. For this reason, I spent the whole night fixing stuff and bumping. Some things are worth noting as might be of help or relieve to the users out there in the outer space.
First of all, new version of vlc: 0.8.5_beta3, or rather test3, that's another prerelease of 0.8.5 version; unfortunately no patches dropped, which means no new fix for things I was fixing myself are fixed yet. It could have been worse tho. Also, DirectFB support is now fixed, with a newer patchset to add a missing AC_ARG_WITH in the configure.ac that seems to have been overseen by upstream in both test2 and test3.
To fix DirectFB support in VLC I had to actually merge DirectFB, which came down to fix libmpeg3 that was badly broken. It was one of the worse makefiles I ever seen in my life. It builds, it's not pretty, it's hackish, but it builds fine, that's enough for me, brr. I'll be glad of removing directfb and libmpeg3 from my system soon.
I merged a patch I had for tvtime to disable xinerama extension into main portage, as Obz seems to be away and upstream sleeping. It's not much of a change anyway.
Old rtorrent/libtorrent versions are gone, live happy with a smaller tree. I also cleaned up my overlay for the ones using it, it now has quite a few packages less, as they are all more or less fixed in main portage tree.
For the cycle "I'm the only one playing FloboPuyo?" ( ;) ), I've added my patch to install a .desktop file with an icon to games-puzzle/flobopuyo, now if you're in games group you'll find it directly on your menu (if you aren't, TryExec will prevent you from seeing the entry anyway).
I bumped KScope as now the legal concerns are fixed. But this is not the usual ebuild that builds and install as it is the sources, you'll get additional value by your friendly neighborhood ebuild maintainer: it moves the .desktop in the right directory to figure on stuff like enlightenment and it installs a sample kscoperc configuration file that already has the paths to the programs it uses, no need to run the autodetection code at all! :P
For the Gentoo/FreeBSD side of the things, I have fixed the clock init.d script so that it actually runs adjkerntz instead of using hwclock, so from next freebsd-baselayout release it will be an actual init.d script rather than a dummy script. Yuppie! :) Also a big thanks to swegener who suggested me to use /etc/cron.d to put the crontab needed by adjkerntz -s to work correctly.
As I was there, I also noted that kerberos support, although present in sys-freebsd ebuilds, too, is untested, and I have actually no clue how to test it, so I've masked the use flag until someone can finally test it, knowing what it does and how.
8:26 local time and I haven't slept. Good, eh?
Still a few updates
So a few more updates, although today was a bad work on my 'daily job' as I had to recode a good part of one of the utilities I was asked to develop when I started the job to integrate it with existing code. I hate adding stuff to others' code, especially when it's missing.
I was able anyway to provide a few updates for my beloved users :P
The first that can be seen is the presence of ALSA 1.0.11 final in portage, and dropping the whole list of release candidates that had to be added to portage just because of the kernel needing them. They are likely to be marked stable soon as they are needed for 2.6.16 to be marked stable, too, so if anyone feels daring to help me, please try them on a stable system. Many thanks, really.
Now from the Gentoo/FreeBSD side I continued my work to get the crosscompile environment, but I'm afraid this will take a while. For instance I'm probably going to merge, for 6.1 version at least, freebsd-lib and freebsd-headers as they don't make much sense divided as they are right now.
Unfortunately this will require fixes to crossdev as we won't have the same two-packages setup as Linux has with linux-headers and glibc.
I'm also going to fix the clock setup sooner or later, I'm getting tired of having it out of sync with my main system, one CEST and one UTC. This will go in a baselayout update I'm going to roll out with a new stage next week, as I found quite a bit of problems in the old stage when I installed it on farragut.
By the way, for who was wondering what I am keywording ~x86-fbsd on the tree, it's mostly what I use, either because I test with that or I'm using the box for. Farragut is going to be my testbed for Ruby-on-Rails so that's why I keyworded it, and I use PostgreSQL as my database of choice.
And last but not least, for who's wondering the fate of pam-0.99... Azarah is having little if any time lately, so he's probably not going to wokr on that soon. Myself, I think I'd need at least two to three days to get pam in a shape to be p.masked in tree, mainly because there are plently of minor glitches and gentoo-specific patches that needs to be ported and possibly fixed to be merged upstream. So I suppose unless someone else steps up, it will have to wait till I get time to hack at it, which means after my current job is finished and before the next one is started.
It's in my TODO list, but not in my priority list, as I'm focusing as much as I can on Gentoo/FreeBSD lately, until I can get a few more devs to help, and to sound/video applications and libraries as they needed a lot of fixes. Joking bit: oh you can of course always bribe me to change the priority of pam ;)
Doing the crosscompile work
So, I've already tried in the past to get a working crosscompiler to FreeBSD from my amd64 box, mainly to distcc stuff.
Unfortunately, to have that working last time I had to install the headers manually, I had to mess with crossdev and overlays, and I only got the C compiler working, not the C++ one.
This time, I'm trying to fix all the stuff up so that I can actually have a decent crosscompiler that can be installed by the usual crossdev actions.
Up to now, I messed with freebsd-headers and partially freebsd-lib, freebsd-mk-defs and a few more stuff. It's not yet straightforward to fix it up, and lots of stuff had to be changed and edited and conditioned, but the results are promising.
I do have FreeBSD's headers merged fine using sys-freebsd/freebsd-headers ebuild, and that's fine. I have a stage1 compiler, that means I can actually build c programs with it. I'm trying to fix freebsd-lib so that it actually merges in crosscompile.
Right now you still need at least sys-devel/pmake and sys-apps/mtree installed manually (a huge thanks to tigger for mtree, or I should have tinkered to add that myself) before running crossdev, and also freebsd-mk-defs are needed for the headers to be installed correctly. The latters has to be keyworded via package.keywords, too.
I'd actually like to be sleeping right now, but I'm waiting for freebsd-lib to at least start to _try_ to build something...
Oh and for those who followed my little rant about shipping costs, I'm probably going to buy the two books from Amazon, as one commenter suggested. The shipping aren't low but they aren't too high, either. Buying only the Agile Web Development with Rails book from Amazon with their shipping costs I'm still paying less than buying the same book (in English) from an Italian e-bookshop.
Still, I'm considering what to do, as it's still €60 to pay now for two books I'm going to receive no idea when :/
Today was a good day for sound
Indeed.
Today while I was thinking over the code I wrote for my programmer's job I iterated over the whole list of bugs for sound@ to try to nail it down a bit. This allowed me to cut my own list off 39 bugs. Some of them closed, some of them reassigned, some of them renamed to "bump/stable request" so they are off my radar.
I'll spend some more time tomorrow on a similar note for media-tv bugs.
This happened while farragut is building the system, as now I can build on Gentoo/FreeBSD without making my system go starving because of VMware. And this is really good for me.
Now there are a few things that i need to fix in the baselayout, then I'll probably roll out a new updated snapshot the next week, as I found quite a few problems while building out of that stage.
Anyway, now I'm waiting for a friend to submit a bug for ALSA on PowerPC that I have to fix, and then I'll see to spend some more time on fixing stuff.. damn I should get a life!
Oh by the way... for the first time for what concerns me, I was able to get a fix for a security bug 9 months before the advisory is released ;) You can be safe with xine-ui on Gentoo :)
I'm going to re-prepare a true G/FBSD box
Finally, after quite a bit of time. What made me change my decision of using vmware-server? Well it's mainly a factor of time and an opportunity I've seen just today.
When I bought the new monitor, I bought one which had a dual input, to use the DVI with my GeForce card for a dual-monitor configuration. This has the side effect that the VGA analog input is not used... and I just never used that before, until now.
I connected the VGA input to the box I used to work with Gentoo/FreeBSD on, and now I just have to press the source button on the monitor to get its output, without need to detach and reattach the connections every time.
Now it's just matter of burning a new LiveCD and re-install Gentoo/FreeBSD on it, from scratch.
I'll do that tomorrow for sure, as I'm probably going to have not much time in the future, if I'm going to find a job that I won't do from home as I'm working right now. From one point of view that's going to take much of my time, but at least I'll be learning how to work as a helper sysadmin in a real environment :)
I'm trying to use all the time I have lately to fix the last issues with Gentoo/FreeBSD and with video and sound and so on. Today I fixed all the bugs for video I could think of. There are still a few that requires a long work, like xine-ui's freeze with horizontal scrollbars on 64-bit systems, but for that I really need more work.
I'll try to fix also a few sounds bugs tomorrow, but mostly there are bugs for jack and professional audio/music production software that I don't have an idea of at all.
Anyway, I hope to be able to help users this way, but I'm not sure how much I can do in these limited days :|
When I'd like to live somewhere else
No this time I'm not referring to the political scene in Italy, but to a practical problem.
I'll be working on a webapplication that has to be written in Ruby on Rails. I'm not exactly a Ruby expert but I know how to use it, I should be able to do what I'm asked to, so it's not a big deal, but as I'm not that used to complex webapplications, I was thinking of buying one of the books that are being written on the topic. I was mainly thinking of Rails Recipes, but as that's not yet printed, I was tempted by Agile Web Development with Rails, too. I'm not a person who likes to spend money for redundant stuff, but if there's something I like to buy is books, so I always thought that money spent on books is always money well spent.
I looked how much would they be, and it was a quite acceptable price, €33 for the PDF and the printed copy of Rails Recipes and €29 for Agile Web Development. Not a bad price after all. Unfortunately, the shipping price is really high: €21 for two books, two times the shipping for a single book. For sure, I don't have so much money to spend to buy both, and buying only one of them, with €10 of shipping is not something I much like.
I'll end up waiting for the two books to be available on Italy e-shops.
Sometimes, I'd like to live on the other side of Atlantic just to have decent shipping prices, sigh :(
GCC and misc updates
A few pointers on the status of GCC on Gentoo/FreeBSD. If you've seen GCC failing to compile lately, it's because protoize was enabled by default on newer revisions of the toolchain eclass, but protoize doesn't seem to build at all on FreeBSD, I'm still investigating that, but it can take a while, so in the mean time it's disabled now.
After that, I've added a simple check to avoid patching and building PIE and SSP support on FreeBSD as they are not (yet?) supported, basically behaving like nopie and nossp were enabled by default on FreeBSD. Instead of 4 specs in gcc-config, now there are only two, one for Hardened compiler without PIE or SSP, and one for the vanilla compiler, dropping the extra specs.
Also I want to thanks Javier again for the work he's doing, he prepared a modified version of imlate yesterday, that I'll use to make sure ~x86-fbsd keyword doesn't end up remaining only on obsolete versions.
I also keyworded Xorg 7's drivers that builds on FreeBSD so that they are available for testing (for this, like other arches, I'm following the idea "it works until proved otherwise", as finding people with all those drivers would prove difficult). I'll have to fix nvidia-glx before committing xorg-x11 tho, so keep waiting for a while still :)
Now, I'm not sure if I'll be able to continue working tonight or I'll just go reading Wizard and Glass until I sleep, but between tonight and tomorrow I'll also have to work on finishing fixing up baselayout with Javier's patches.
By the way, I'm interested to see if there's someone wanting to work on the support of GNOME on Gentoo/FreeBSD: what it's needed is collaboration between Gentoo's GNOME team, FreeBSD's GNOME team and upstream GNOME developers, so that the efforts aren't redundant nor unportable... yeah it's not an easy or quick job, but it's useful, and if you are a GNOME fan, you might want to give your hand here ;)
KDE works, and XFCE used to so it might still be working already, I haven't tried yet. Enlightenment 0.16 out of portage works, I'm not sure about E17 as there's a patch needed, that I've prepared for E16 but haven't tried on E17. I'm interested in trying it actually, as it seems quite cool, for a WM, and I might want to use it as my WM of choice in testing Gentoo/FreeBSD.
Time to return to work!
Proceding the Init way
So, now that the ~x86-fbsd keyword is being spread on tree, a part from fixing the dependencies on the optional stuff I haven't keyworded yet, I've started also fixing some issues with baselayout and init scripts.
I want to thank Stefano Takekawa, Robert Sebastian Gerus and Javier Villavicencio, who helped by testing and providing bug reports, init scripts and patches to base on. A new freebsd-baselayout is released, along with a few revision bumps of sys-freebsd packages: now net scripts sets routes correctly, included metrics; net.lo0 doesn't warn anymore (both of which are fixes provided by Javier); pf and powerd have init scripts (respectively Robert's and Stefano's); man pages for machine-dependent drivers are installed alongside the rest of manpages to be available to users, and other misc fixes.
enlightenment 0.16.8.1 has a patch and it's keyworded in portage, I'm trying to get a hold of someone in #e @ freenode to get the patch merged upstream, so that the live CVS version would work (and thus I could try e17 ;)), and ffmpeg is fixed (in the mean that CFLAGS are no more ignored so -fomit-frame-pointer can be used to build mmx code and free up a register to allow building).
I've also keyworded tetex that solved a couple of optional dependencies for documentation and stuff. dev-libs/check is still a problem. I'll be keywording some more stuff in the next days, to cover the possible basic needs of users, not much stuff, but at least enough to make Gentoo/FreeBSD usable :)
Unfortunately vmware-server doesn't seem to handle sound support that good, and I can't test it at all. I'll have to find time to reinstall Gentoo/FreeBSD on a real box to work on, it would also help me with the building as I can test two things at a time that way.
I'm thinking if it's worth to release a new stage, with the recent fixes to baselayout, but I'm still not sure, as there are little fixes actually.
Oh a thing.. as there was an interesting discussion about the branding of stuff in Gentoo, although the outcome is still uncertain, I'd like to be able to have something to brand with, if the branding is accepted someway, but of course most of the artwork will be for Gentoo Linux...
Now, we do have the beautiful logo that Marius Morawski drawn, would it be pushing it asking for people to prepare (possibly svg) wallpapers and kde splashscreens? :) (I say KDE because that runs already, if GNOME will be fixed, that would do too).
Lots of updates, and good news.
It's been a while since I last blogged; the reason is found in the recent Italy's elections; I wanted to avoid ending up talking about italian politics. But now elections are ended and I can restart blogging :)
First of all, start with news of the day, Daemon News published an interview done by David Stanford to.. me :) I want to thanks David and the Daemon News staff for this opportunity.
Part two, amaroK 1.4 crazyness... okay I know many people are going to hate me because of the series of bumps of amarok 1.4_beta3. Unfortunately there were a few problems with the released tarballs, regressions since the _rc we all tested, that ended up requiring a final 1.4_beta3c tarball release (1.4_beta3-r2 in Gentoo).
The major change since this release is that xine is no more optional. Upstream decided that one between helix and xine engines had to be built for amaroK to be considered complete, and being helix available only for x86, I did go with xine. If you want gstreamer backend you can select it, but it might not be available in final release as it lacks proper (upstream) maintenance. Xine works in most cases tho, just remember to enable mad useflag if you want to play mp3s.
From the Gentoo/*BSD part, I want to thanks Mike for adding the ldhints patches to Gentoo patchsets for binutils 2.16.1-r2 and 2.16.91.0.7, and Nick Clifton (from upstream binutils) who applied that patch on upstream, too. This means that right now binutils from HEAD supports FreeBSD completely out of the box! Yuppie! Well --as-needed seems not to work, I have to fix that, but that's lower priority.
I'm still working on baselayout, as there are still troubles, for example rc-daemon doesn't work as intended, and currently all the filesystems are checked twice (this is fixed in SVN thanks to Javier Villaviciencio who reported it), and dhclient fails to set routes. Most of this will be fixed soon tho :)
Also, Xorg7 works, KDE 3.5 works too. kdebase-meta, kdenetwork-meta and kdegraphics-meta are (almost fully) keyworded and works fine. I had to add a last minute fix to mesa to get rid of -ldl from .la files installed, so if you have it installed and have problems linking due to libdl missing, run the following command: sed -i -e 's:-ldl::g' /usr/lib/libGL{,U}.la /usr/lib/opengl/xorg-x11/libGL.la, and that it will fix it.
sdl seems to work, too, so I'm going to keyword it together with flobopuyo (my favourite game and what I've tested a lot with ;) ) later on, although you need the patched libusb 0.1.12 from the overlay if you have libusb already installed, as 0.1.11 has a bad bug that makes libSDL fail to find the usb joystick support on FreeBSD and ends up failing because of undefined symbols on the final library.
Right now I've talked with UberLord and I might know what the deal is with dhclient, but I can't test it right now, I'll wait for arachnist to test, and in the mean time I'm going to bump alsa to 1.0.11_rc5, sigh.
Anyway, the binutils patch merged upstream is really a milestone for me... next step, patching gcc to recognise the extra format strings added by FreeBSD while using the right FreeBSD target :)
I'd like to contact some FreeBSD developer to submit the patches to build freebsd-lib and -sources with binutils 2.16 but I'm not sure who to send them to :(
A "Thank You" to VMware guys
I really want to thanks the VMware guys for their vmware-server... today the beta2 was released, and tonight I was having a few issues with vmware-server itself, so I decided to update it and see...
I was about to curse for a while, as it was really giving me hard times with slowness, but then I seen it had somehow started also another virtual machine I didn't need. I started the Gentoo/FreeBSD 6.0 VM and.... magic! the "negative runtime" warnings that were coming up during the boot phase are now gone! Great! Thanks VMware.
Anyway, the stage is now on my home on dev.gentoo.org, waiting for one of the mirrors' admins to pick it up and put it on mirrors.
Right now I"m testing Emanuele's patch to build freebsd-lib with newer binutils, I hope vapier will merge my patch into binutils for tomorrow, that would really help.
Anyway, now it's 2:27 and I _really_ need to sleep as last night I haven't sleep at all (and slept only during the afternoon, 11-16).
It's fortunate that I can conciliate the work on Gentoo/FreeBSD with my actual job, if I were to have a way more committing job, I would have to drop most of G/FBSD maintenance, and that would be bad at the current status :(
Stagebuilding again
So, as I promised to a couple of users before, I'm going to provide an updated Gentoo/FreeBSD 6.0 stage this week. What will figure in this updated stage? Lots of new shiny things :)
First of all, the new baselayout, where the net script actually works for routes, too. It still has some glitches, for example stopping cups or openntpd causes a termination :( but this is still a minor problem. Consider this is still experimental so please submit any bugs you'll find in Bugzilla.
There's also an updated version of binutils, 2.16.1-r2 fixed with the FreeBSD patch; I was almost going to provide a 2.16.91.0.7 version, but then I remembered that I still have to patch freebsd-lib to build with it with the patch kindly provided by exg :) (who also explained me how to fix these kind of issues, thanks exg).
There will be a newer GCC too, but that's not much useful. It will solve two big issues, namely the libarchive/bsdtar merge and expat's soname change. You'll also find a couple more packages, like cronbase (used by freebsd-ubin to have cron.daily directory, as locate now has updatedb working without periodic) and pidof, new dependencies added when sanitising ebuilds for main tree merge.
Oh yeah this will also be the first stage only using ~x86-fbsd keyword, the first one using in-tree packages (although you still need the overlay). It will featurea also vim, for the pleasure of its users.
Please note that currently the ~x86-fbsd tree is _not_ complete, there are things like tcp-wrappers that are even in system but if enabled will ask you to keyword stuff ~x86, and USE=doc and USE=test are not yet fixed... I'll do that time allowing.
There's also a new portage in the stage, although when 2.1_pre8 goes out I'm going to strictly require that on profile, if antarus is kindly enough to implement per-package use.masking in it :)
Anyway, I hope to be able to prepare updated stages more quickly in the future, even if vmware-server has still issues..
I think that, after an year, we really had big improvements. I had a bit of a mess up last fall, and with newer versions of xorg it wasn't working anymore, now thanks to Xorg upstream and the modular release, we actually have a working Xorg, and I started keywording stuff so that it won't disappear easily. Right now it's possible to have a quite minimum system but working fine... well minimum depends what suits you, it _does_ have most of xorg keyworded and kdebase, too....
Oh well ;)
New VLC in portage
Okay a multimedia update, someone will hope this is going to be my last (or one of the last) blog entry, as seems like whatever I do, I break something (in their dreams maybe, who knows).
I've committed to portage, under package.mask, vlc 0.8.5 test2 . Please give it a try and report of any problems found, either to me via bugzilla or directly upstream.
I hope there won't be anything particular, but testing it is not a bad idea, also because it started to use libtool now.
Okay I think this is just a quick update about it so that people will know about.
The case of the missing --as-needed
(Another quote title, although not of the same continuity than the two before, this time it's Meitantei Conan ;) )
So seems like the recent breakage due to expat changing soname from libexpat.so.0 to libexpat.so.1 shown to some fellow devs and to other advanced users that --as-needed can be useful. I had a total of 9 files linking to libexpat, and I just needed to rebuild fontconfig to have KDE still working, no rebuild of qt, kdelibs or any kde package at all.
Many people asked me about --as-needed lately, so I started providing more often my --as-needed fixing guide link, as that tries to summarise more or less what you have to know about that flag and the way to fix packages not supporting it. I wish to thanks antarus who cleaned it up, as it used to suck grammatically more than it sucks for the content.
Still there's who likes to be prissy about these things, wondering why that guide is in qa as "--as-needed is rice"... oh well, if --as-needed is rice, then hardened is rice too, selinux is rice, mips porting is rice..
I don't see how someone can define rice something that makes the linker work as it should have done rather than following blindly what a developer (that might not even know how a linker work) told it to do.
Anyway, I hope that the attention that --as-needed got recently will help with the efforts to fix the packages that doesn't work with it so that we can actually start suggesting that to users, as that limits the breakage in case of soname change to the actual packages making use of the changed library, rather than almost the whole system.
Oh a side note, I'm sorry for the wrong patch in drkonqi/kdebase I committed tonight, seems like I was half asleep when I decided to change from the patch full name to ${P}... anyway now with that patch you're able to get decent backtraces with drkonqi also when using splitdebug, be happy! :)
My kdebase-meta
(again, a quote from a TV Series I like, this time Scrubs...)
Okay so I've found my problem with the mouse I was having before, /dev/sysmouse does not work, the right device is /dev/psm0, although xorgcfg doesn't recognise that, I might have to tell that to the Xorg guys.
Anyway, now that the problem is solved, I've keyworded also xf86-input-vmmouse that's the driver I'm using right now.
After keywording the part of xorg I actually installed and thus made sure it works, I wanted to restart the work on KDE, while I'm still validating sys-freebsd ebuilds so that i can put them on tree in the next days.
I've keyworded quite a bit of the dependencies, but I'm now waiting for Qt to build. I'm sure it works, it always worked, but I have to compile it first.
Although sys-freebsd is still to be committed, I managed to keyword the base system and most of the important utilities we have, like portage-utils, screen, vim, and so on. gcc and binutils 2.15 are keyworded, 2.16 requires the patch that Mike hasn't merged yet.
I have to say that I have left as RDEPEND.badindev most of the dependencies for doc and test useflags, as I don't have time to test these right now. I also haven't use.masked stuff I didn't know already broken (like java for example), so you might get problems, they'll be fixed, somehow.
I actually miss working on a real machine rather than a virtual one: a virtual machine is easier to monitor the console of, but it shares the compile power with my own workstation and that's pretty annoying on the long run. I might reinstall the box I have here sooner or later, but right now going to move the monitor connection from one box to the other is really not the case, especially as from today I'm working pretty hard on my paid job.
The one with xorg-server
(If you didn't get the title, it's a reprise of the title format for Friends, one of my favourite series.)
Last time I provided interesting screenshots... this time I won't as I'm not yet done and I'm still fighting with it, but Xorg modular builds and runs on Gentoo/FreeBSD, yai!
The only problem remaining is that /dev/sysmouse is silent even when i put the mouse on VMware and try to move it... maybe I've forgotten something on kernel configuration or VMware is being silly.. yet to find out.
Now as people might have seen yesterday by #gentoo-commits or by my commit log, I've merged the Gentoo/FreeBSD profile into main tree and started keywording ebuilds with ~x86-fbsd keyword.
What does this mean? Well the first important thing is that finally we don't risk to see packages go away when they are the last version supporting gentoo/freebsd, but also we'd know when something requires more porting.
Unfortunately keywording everything alone is going to be a big problem, also because I have an hacked perl in my main PORTDIR to support LDFLAGS, and I still have to test it thoughtfully so that Michael will accept it, so I haven't keyworded that yet, I'll do it later today probably.
I'm also going to retry with sandbox later, although I'm not sure how much I got it right this time. The code should work, as it works on NetBSD at least, remains the usual problem with findutils and the call cycle.
Oh of course I'll also be merging patches to fix build issues with GCC 4.1, with glibc 2.4, with libdvdread 0.9.5-r1 and also providing patches to avoid stripping binaries and to respect LDFLAGS, as well as improving modular xorg porting when i can ... if I find time to do this of course, as I'm also working on a paid job right now... I need longer days.
The xine-lib snapshot and fonts issues
Okay maybe some of you noticed that yesterday I committed in portage my fist CVS snapshot of xine-lib. This is not, as I do with mt-daapd or with vlc, a nightlie, it's a true CVS snapshot I've prepared myself. It's not safe from patches either, as many things needed to be changed anyway, so I prepared also a patchset to go with it.
There shouldn't actually be much changes in that snapshot, but I had to try if AAC was working without and with my patch... seems like nothing changes from 1.1.1 tho, my patch is needed or xine-lib will crash badly when playing an AAC file, I can play stereo AAC file, but some people gets a device occupied error with them, and 5.1 AAC files doesn't play at all.
I'm actually hoping for the new aac decoder in ffmpeg to finally have an alternative to the obnoxious faad library that doesn't work as intended on 64-bit systems even after patching the hell out of it.
This post is going also to be of public usefulness.. if anybody but me, using modular Xorg, started having fonts problem after last week, like sites not rendering the chosen font but rather some strange, non antialiased, crappy font, it might be because it's falling back to Helvetica, Arial or Times fonts instead of the sans-serif or serif fonts set in the browser. Last week the media-fonts/font-adobe-75dpi was forced on me on the modular Xorg setup (I haven't tried looking at what it's bringing it here), and that caused Konqueror to lookup the fonts there instead of using my own fonts when a site was listing something like "Tahoma, Arial, Helvetica, sans-serif".
I wish to thank foser today for helping me sorting out the problem, that can be solved by disabling bitmap fonts in fontconfig, forcing the system to get only truetype fonts (that doesn't look that bad); also thanks to exg who suggested me a quick way to do so, with the current ~arch version of fontconfig:
cd /etc/fonts/conf.d && ln -s {,10}no-bitmaps.conf
If anybody found the same problem, this should fix it.
Now I'm wondering if I can set fontconfig to replace the Microsoft fonts from media-fonts/corefonts with the similar fonts found on arkpandora, so that I would display webpages as the authors intended without having to install Microsoft fonts.
Intrusive debugging
I was never a fan of "on the spot" debugging, I'm more an analyst when it comes to finding problems with the code, I put some printf() here and there, and I look how the code flows.
As my current job has to run on an embedded ARM system, I was interested in making sure the code was perfectly fine before going to try it on the actual board as it's not exactly performant, so I tried to make more use of gdb as debugger to ensure the reliability of my code.
Well it seems like mine was a big big error. I passed the night debugging my code, trying to find why I asks for some threads to be cancelled and they aren't, then today I tried running the code outside gdb, and it works just great.
I think I'll stay with less intrusive debugging for the rest of my life :)
:: Next >>