Well, I'm sorta scratching my head over some version disrespectancies between the 2004.3 and 2005.0 trees, which has caused me to add even more packages to the direct list of things to be emerged.
The current list is now taxing just below 500 packages on the list. Rolled out a call for packages onto gentoo-user, hoping to see what users want. Not that I really believe our target audience bothers to read gentoo-user, but still its worth a try.
Syncing up the specfiles in granularity and doing comparsions now. Fun fun fun.
...btw. openbox+pango, broken configure check, and the pango code miscalculates fontsizes to pixels.. bleh.
Okay, the first bootstrap was a success. I'm tweaking specfiles to get system packages built earlier in the process, as well as updating the first set of binaries for you people out there who are restless.
kdegraphics has a missing link dependency on lcms, either install lcms, or rebuild kdegraphics. Will make a fresh build.
For now I'll see if I can put a fuser -k on the tempdir in catalyst, ought to solve the umount problem due to lingering gconf process'.
Update:
okay, gcc update was a minor one (pfhew ;) , and I got the stray-process killing patched in (wee) . Doing a rebuild again to see if I can get kdegraphics to link properly. Other than that, I'm starting to become satisfied with this. :)
Morning, More builds in progress. Seems gcc is very late in the depchain, wonder why, need to use the tree function and see if I can push it earlier, then force a complete rebuild.
I'm not happy.
Working on Project Chinstrap builds again. Now with the official Gentoo 2005.0 builds for base. Current progress on the Project Chinstrap 2005.0 ChangeLog.
Files will be appearing at the binary repository as time goes.
I'm bootstrapping the whole build from the official GRP cd's, using the same set of USE flags as the cd has, however, I've updated the package count to match the Chinstrap 2004.3 package list.
In other news, I'm rebuilding X with support for bitmap fonts in order to get Ted tested and upgraded. Commited a buildfix for 2.12 in order to get it running so I have a comparative system to start with here.
Chinstrap builds will be late. Machine locked up and the last thing on my console was scary messages about ext2_check_page: bad entry in directory .....
booting init=/bin/sash and fscking disks now...
*sigh*
Add to this that I previously managed to do :
mount --bind /mnt/distfiles
chroot
rm -rf /usr/portage ...
....
which of course wiped my NFS r/w shared distfiles from all machines ....
I'm right now, very very tired and should go to bed before I do something even more stupid.
Ach, needs a RDEPEND on gpg-error,
http://bugs.gentoo.org/show_bug.cgi?id=86456
Bleh , seems that chinstrap builds got slapped in the face again. more packages that need touchy-feely in that you require a .config for the kernel to build them.
Annoying, I don't want to hand touch such, I'll have to setup something that simply does "make oldconfig" in a post-launch environment. .-/
or I'll have to fix the original issue, but that is work :p
update:
cdrtools +crypt (default USE flag) has a dependency on cryptsetup, which requires a kernel to be configured in beforehand in order to even build.
Seems I have to patch around this, create a "kernel-config" package and install, or something such. :-(
Grmfs.
grep headers /usr/portage/profiles/default-linux/x86/2005.0/packages
>=sys-kernel/linux-headers-2.5
grep headers /usr/portage/profiles/package.mask
...
>=sys-kernel/linux-headers-2.6
....GRMFS.
Okay, I watched with Ire as Eugenia brought an Off Topic discussion into desktop-devel list [1]. Among the first responses was a request to take the discussion to a more fitting forum. ignored.. After the thread goes on she is in more or less sharp words being told that she's wasting bandwidth and asked to be quiet, and things calm down.
For a few hours, until she posts another incoherent ramble [2] to her weblog (Oh, sorry. "Journalistic Outlet with Proffessional Attitude") [3]. This ramble was spotted by Thom Holwerda who does a short analysis of the situation [4] and suggests a solution.
However, Right now, I want to adress some of the points that Eugenia so delightfully steps into with her self-centric complaints about being ignored.
*) She asks about a way to make her voice heard.
*) She wants to post her requests, blog it on her site (sorry, "Write professional and welformualted articles about it") and get enough "voices" that developers will feel forced to implement it.
*) Failing that, she wants material enough that "Gnome sucks because it ignores all theese voices" for future articles. (that will give her ad revenue).
As several people stated in the thread, the kind of people who read her journals, or find dedicated voting sites (or bugzilla) are -not- the average joe user of a Gnome desktop, and therefore give a very slanted view of things.
However, lets see about what we actually -do- in this case, in order to see if we can make this a bit better.
a) Feature Requests from the desktop [5]
b) Feature Requests from a web page [6]
c) Feedback from devs
Here comes the tricky part. No bugs peter out and die out of obsolesence. They must all be explicitly closed, with a comment from a developer. This means that sooner or later all bugs have to be cared for, and your Feature Request will be seen and answered.
There are also the Bugsquad and BugDay [7] projects, along with gnome-love [8] to take care of this vital part.
Adding to this, Jacub Steiner recently wrote a very good piece on Getting functionality implemented by a volounteer hacker [9] that also caters to the aspiring Feature Requestee's.
The solution to this "issue" of Ignored Whining Webloggers without the capabilty of coherently expressing themselves lies -not- in duplicating this effort. Such a solution only fragments our already lacking resources, and doesn't solve an issue.
As a developer, you value consistent approaches. You don't want to have to scourge some journalists hodgepodge forums after obscure bugreports, you want them delivered in a way that you can track them and contact the reporters for more info. You especially do not want to see somone else voting to make more work for you by duplicating pre-existing issues out of sheer laziness.
So, in order to get this down as a bit more concrete suggestions.
What can we do about it?
*) make "Feature request" more obvious. Alan had a great suggestion about "did this help?" . Combine with automatic filtering and duplicate checking, and we have a good entrypoint.
*) Make Bugzilla Feature Request more simple to find.
*) Polish up Jacubs text and put it in on the introduction page on Bugzilla for Feature Requests.
*) take harder moderating steps towards people on desktop-devel.
*) Make "join gnome" easier, smoother, and simpler. Spoonfeed people, if need be.
*) Seek refuge in great people such as Anne Østergaard[10] and do not become gender biased or prejudiced.
[1] http://mail.gnome.org/archives/desktop-devel-list/2005-March/thread.html#00078
[2] http://www.osnews.com/story.php?news_id=9933
[3] http://www.osnews.com/
[4] http://www.expert-zone.com/index.php?module=announce&ANN_user_op=view&ANN_id=750
[5] http://mail.gnome.org/archives/desktop-devel-list/2005-March/msg00191.html
[6] http://bugzilla.gnome.org/simple-bug-guide.cgi
[7] http://developer.gnome.org/projects/bugsquad/
[8] http://live.gnome.org/GnomeLove
[9] http://jimmac.musichall.cz/weblog.php/Design/Speccing
[10] http://mail.gnome.org/archives/foundation-list/2005-March/msg00007.html
Bloody abiword, again. Builds against Nautilus private interfaces to create a nautilus view.
Views are deprecated in nautilus, so with the nautilus private (non ABI stable) interfaces changes and changes version number, abiword breaks without a word.
Bleh.