Gentoo Security Project Summary -- was Re: [gentoo-dev] Project summaries
Gentoo Security Project Summary Short Summary: The Security Team is up and running, but we are dealing with numerous tasks and a high load in daily maintenance. Fresh blood is not only appreciated, but needed to continue the luxury of Security Support we currently have. We have too many open bugs, too many undrafted GLSAs that are eventually sent too slow, and a lot of channels to monitor. There are some bugs that need extensive amount of work to be resolved. The Security Team is also developing applications to support our workflow and user's systems, such as improvements to glsa-check and our DTD, a new Ruby on Rails application to draft GLSAs and an application to coordinate Kernel security support and check local systems. == Personal changes == === Lead Election === Since the last election had been longer than a year ago, we held a new election during the first two weeks of May. It was determined unanimously that Pierre-Yves Rofes (py) and Robert Buchholz (rbu) will be the new French-German duo that is our Team Leads. We would like to publicly thank Raphael Marichez (falco) and Matthias Geerdsen (vorlon) for doing the job the years past. They were both not available for another term. === Additions to the team === Alex Legler (a3li) recently joined the Security Team. However we still need more people helping with the daily maintenance work. This call for help applies to both developers and users. For more details on how to join the Security team, see: http://www.gentoo.org/proj/en/security/ Or, more specifically: http://www.gentoo.org/security/en/padawans.xml http://www.gentoo.org/security/en/coordinator_guide.xml http://www.gentoo.org/security/en/vulnerability-policy.xml http://www.gentoo.org/security/en/bug-searching.xml == Maintenance == === Bugs and GLSAs === We have reached new highs in the number of open bugs and the length it takes all of us to resolve them. A shortness in Gentoo developers in general and on our team is leading to three issues: (1) Security bugs are not resolved by ebuild maintainers Some security bumps are staying open for weeks with teams not responding to pings. Even issues that could be resolved before being public (what we call "embargoed bugs") are not resolved due to maintainers not being responsive on such bugs. In fairness, I have to note this is limited to only some herds and not architectures. Architectures and in particular their Arch Security Liaisons are doing their job in a reliable and timely fashion. (2) GLSAs are delayed We're slow! We are sorry. I feel this is a great disappointment especially in those cases where maintainers and arch teams are doing a fast job and we take 4 weeks to write the accompanying GLSA. I see potential for improvement with the GLSAMaker rewrite described below. Contributors to GLSA writing are greatly welcome. (3) Security Team is not resolving bugs either In the past, we have been conducting simple version bumps ourselves or have masked vulnerable ebuilds. Currently, doing other people's jobs in the security process is mostly on hold as we have a hard time struggling to cope with our part of the job. === Documentation update === We actually updated our existing documentation to reflect more of our security process. Isn't that awesome? Read our project pages to find out more: http://www.gentoo.org/proj/en/security/ === GLSA dtd and glsa-check === We have been discussing changes to the GLSA DTD for ages now. There's few people interested in the subject and I have been slacking on it. I have picked up glsa-check maintenance recently and we will announce changes to the DTD to the dev lists as soon as they are fully drafted. Since the GLSA format is supported in all package managers, the change will be announced at least 6 weeks before going live. Oh, and glsa-check will see some bugs fixed, I hope. And support for UTF-8. And support for mask-glsas. Hmm.. anyone else here to help? glsa-check changes in 0.2.4: http://sources.gentoo.org/viewcvs.py/gentoolkit/branches/gentoolkit-0.2.4/src/glsa-check/ glsa-check changes in trunk (0.3): http://sources.gentoo.org/viewcvs.py/gentoolkit/trunk/gentoolkit/ New DTD proposals: http://git.goodpoint.de/?p=glsa-check.git;a=tree;h=refs/heads/glsa-2 == Feature extensions == === GLSAMaker === The GLSAMaker is a web application that we use to draft, comment on and refine GLSAs. It allows for the export of the GLSA texts and XML files you might know from gentoo-announce or /usr/portage/metadata/glsa. The application is considered helpful by all of us, however its shortcomings require to duplicate some work that could be automated and its usability makes working with it less fun than it could be and slows our work down quite a bit. Alex Legler (a3li) and Pierre-Yves Rofes (p-y) are currently working on a rewrite that covers the current functionality and extensions to ease the workflow dramatically by integrating metadata from Portage, Bugzilla, the CVE database and Secunia. We are
Re: [gentoo-dev] Project summaries- kernel
Christian Faulhammer wrote:
Hi,
any project lead/member can post an answer to this mail for a status
report:
kernel:
Continues to be a small team with desires to grow. Our processes scale
well but recruitment does not. Only real task is to handle
gentoo-sources, 90% of the time is handling upstream bugs reported by
users (the kernel is so big and fast-moving that in order to be more
effective, we have to do a certain amount of work before sending users
upstream).
gentoo-sources patchset continues to shrink, we're very close to vanilla
which is great from a working-with-upstream perspective.
I'm not finding much time to devote to the project due to other
commitments (seems to be an ongoing curse that occurs to anyone taking
the 'lead' position). Not likely to change very soon :( Happy to
consider proven contributors for taking over the lead position, past
present and future.
Mike Pagano continues to be a driving force, continually attacking bugs,
wranging patches and making releases.
Recruited George Kadianakis and Markos Chandras who have helped a lot.
Need to spend more time integrating them and delegating more from me and
Mike.
Overall in good shape with 22 open bugs.
One real drain for us is dealing with crazy gentoo devs who decide to
maintain packages of kernel code outside of the kernel (i.e. external
kernel drivers). These break really often because these external
packages use the internal kernel API which is deliberately unstable.
Many maintainers are responsive, but very often we have to deal with
unresponsive maintainers or packages which simply can't be fixed easily,
this eats a lot of our time, slows down stabling processes, and results
in a bad experience for our users. Asking for extinction of all such
packages is probably unreasonable, but it would be good to see them kept
out of the stable tree or something like that, and we could do a better
job at communicating these maintenance difficulties to our users ("use
at your own risk, this will probably break next week").
My ideas for potential goals/improvements, totally dependent on time and
interest from team members:
- get bugs upstream faster
- fewer and fewer bugs
- accelerate stabling to the previous rate of 3 weeks after every major
release from upstream. (quite time consuming)
- speed up regression handling, prioritise higher
- work more with bugs that we send upstream, right now they get a bit
neglected by us and sometimes by upstream (probably have 30-40 bugs in
this state)
- move genpatches website to independent location, automatically
generated, with permanent/reliable tarball hosting
kernel-misc: Maintains various userspace packages that are tightly
linked to the kernel e.g. jfsutils, module-rebuild, fuse,
also the kernel-2, linux-info and linux-mod eclasses.
Mostly neglected. Some packages have active maintainers, thanks! For the
others I usually do a bug sweep every 6 months or so, taking out the
easy bugs and applying patches from users.
Goals/improvements: find people to take care of this stuff..preferably
people who can just step in and get on with it without me needing to
find recruitment time.
Re: [gentoo-dev] Project summaries
On Sun, 2009-05-10 at 18:45 +0200, Rémi Cardona wrote: > > Medium term : > - libxcb 1.2 will be moved to portage once we figure out a sane way > to > handle the disappearance of libxcb-x11.so. For those who haven't > heard > or seen what happens during the upgrade, let's just say that the > upgrade > from expat 1.95 to 2.0 was a walk in the park compared to this. An important difference to note here is that expat case (sorry) was hit by everyone, but xcb problem will be hit only by people who have enabled USE=xcb on certain packages or globally, and that is not the default. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project summaries
Ulrich Mueller schrieb am 10.05.2009 23:08: > > > Eselect project: > > I've joined the project one month ago. Looks like it's my duty to > write a status report. ;-) > Thank you for bringing the eselect project back to life. -- Daniel Pielmeier signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project summaries
Le 10/05/2009 23:43, Gokdeniz Karadag a écrit : It seems like you have forgotten the link. [1] https://bugs.gentoo.org/show_bug.cgi?id=267769 Thanks
Re: [gentoo-dev] Project summaries - KDE team sumary
On Monday 11 May 2009 00:44:11 Pacho Ramos wrote: > El dom, 10-05-2009 a las 20:54 +0300, Markos Chandras escribió: > > We did quite good job in pushing Qt-4.5 packages really quick. We have a > > stabilization process for 4.5.1 packages[1] as well. We maintain many > > qt4 > > I cannot see "[1]" link, seems missing in original mail > > I think that it's: > http://bugs.gentoo.org/show_bug.cgi?id=266201 > > Best regards :-) Oooops missed that :). Indeed this is the link -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Project summaries - KDE team sumary
El dom, 10-05-2009 a las 20:54 +0300, Markos Chandras escribió: > We did quite good job in pushing Qt-4.5 packages really quick. We have a > stabilization process for 4.5.1 packages[1] as well. We maintain many qt4 I cannot see "[1]" link, seems missing in original mail I think that it's: http://bugs.gentoo.org/show_bug.cgi?id=266201 Best regards :-)
Re: [gentoo-dev] Project summaries
> On Wed, 6 May 2009, Christian Faulhammer wrote: > any project lead/member can post an answer to this mail for a status > report: Emacs project: Christian has already reported, and I think he has covered the major points. So nothing to add from my side. Eselect project: I've joined the project one month ago. Looks like it's my duty to write a status report. ;-) * eselect-1.0.12 is out since three weeks. I've fixed most bugs (a dozen or so) that were open in bugzilla. So far, no regressions have been reported, so this version will be good for stabilisation soon. Hopefully this is also the last release from the 1.0.x branch, whose retirement is (IMHO) long overdue. * The eselect trunk has some new bells and whistles, including: - support for OpenRC in the "rc" module - "package-manager" library has been updated for Portage 2.1.6 - new "modules" module, for listing and querying eselect modules - modules for EDITOR and PAGER environment variables - "news-tng", yet another module for reading GLEP 42 news (mainly with better Portage support) - the dysfunctional "mailer" module will be removed - more bug fixes; some of the reports are open since 2006 :-( There are still some things to be done before the release of version 1.1.0, but I hope that it will be ready in the second half of this month. Ulrich
Re: [gentoo-dev] Project summaries
On Wednesday 06 May 2009 09:49:53 Christian Faulhammer wrote: > Hi, > > any project lead/member can post an answer to this mail for a status > report: > [..] Maybe, it would be nice each project, that wants more manpower, to update this[1] page, so that users would know what projects need more contribution :) [1]: http://www.gentoo.org/proj/en/devrel/staffing-needs/ -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Project summaries
On Wed, 2009-05-06 at 08:49 +0200, Christian Faulhammer wrote: > any project lead/member can post an answer to this mail for a status > report: The Ruby project summary: We've had two new project members recently: a3li and gengor. In addition we also have a number of new people who help out on occasion with our overlay. More ruby versions are now available: - Ruby 1.9.x is in the tree. It's masked for now pending more testing and pending getting the tree more ready for it. - Ruby Enterprise Edition is available in our overlay. - We also have the latest ruby 1.8.6 and 1.8.7 versions in our tree. We are in the process of cleaning up the eclasses and getting them ready to support multiple ruby versions as well. We have a Summer of Code project which will deliver a tool to treat Ruby Gems as first-class citizens in Gentoo, including such things as patching and testing. We hope that this will improve the quality and quantity of ruby code that we can offer. Future plans: - Complete ruby 1.9.x migration and unmask it. - Get Ruby Enterprise Edition ready to move to the main tree - Add Summer of Code tool to the tree and convert majority of current ebuilds to use it. - Recruit more people: while we are not in bad shape right now we could certainly use one or two more people to keep things moving along. - Get our open bug count down. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project summaries - SPARC team summary
We are an architecture team, so except for one developer (bluebird) who is actively working on true multilib support (64-bit userland), we are mostly reactive to bug reports for security, testing, and keywording. Currently we have enough developers to pretty much keep up with demand. However, note the following: 1. We need arch testers. We use them to help with evaluating keyword requests and as a breeding ground for new developers. However, because of this all of our arch testers have become developers and we need to refresh the pool. 2. Although we currently are keeping up with requests, the work load is heavy enough that we face (in my opinion) a real risk of developer burnout. Thus, I would say that we are understaffed, although we have one or two candidates in process. I'd prefer to have about three more developers as well as arch testers as mentioned above. So, short term, we are in reasonable shape. Longer term, we need to recruit. Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] Project summaries
On Wed, 2009-05-06 at 08:49 +0200, Christian Faulhammer wrote: > any project lead/member can post an answer to this mail for a status > report: > XEmacs: > graaff is the lone wolf here and because upstream development of XEmacs > is not really on fire, he has not too much to do, I think. He > introduced eclasses in a similar way as the GNU Emacs team. Actually there is work to do on XEmacs, but my work on the ruby project seems to take precedence all the time. :-) Plans for XEmacs: - bring tree in sync with upstream released elisp packages - bring xemacs 21.5.x to the tree from the overlay Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project summaries - KDE team sumary
On Sunday 10 May 2009 19:18:04 Jorge Manuel B. S. Vicetto wrote: > Christian Faulhammer wrote: > > > Hi, > > > > > > any project lead/member can post an answer to this mail for a status > > > report: > > Hi. > > Gentoo KDE team status report. > >[..] > -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org > Gentoo- forums / Userrel / Devrel / SPARC / KDE Hello there :) Qt Herd, as part of KDE project, status report: ***Overlay status (qting-edge)*** Even though we are 2 developers and 1 contributor , we manage to keep this overlay in a pretty good shape. In this overlay we maintain 3 different qt versions *4. which is the master branch from nokias' git repository *4.5.[qt-copy] which is the Qt maintained by KDE developers *4.5.[-qt-copy] which is the 4.5 branch from nokias' git repository. Plus we maintain many Qt4 live packages ***Portage tree status*** We did quite good job in pushing Qt-4.5 packages really quick. We have a stabilization process for 4.5.1 packages[1] as well. We maintain many qt4 packages and we add more and more every day (ye, because we are quite crazy about Qt4 \o/) . In general I can say that Ben(yngwin) and me can handle the load pretty good so far. At least this is what the number of qt bugs reveals :P On the other hand the future doesn't look that good :( Both of us we ll have extremely limited time after July . Ben is moving to China and I ll join the army for a year. So we really really really like to make sure that Qt4 will be in safe hands :). However, there are 2 upcoming developers who, hopefully, will be full developers withing the next month so we can train them about qt4 split packages and qt4 eclasses. Ben if you think that I missed something let me know :) -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Project summaries
Le 06/05/2009 08:49, Christian Faulhammer a écrit : Hi, any project lead/member can post an answer to this mail for a status report: X11 Herd Status Update Short term or recently done : - 1.5.3-r5 went stable (I'm sure y'all noticed) - there will be another 1.5 stable server within a few weeks - 1.6.x will go into ~arch pretty soon - alpha is pretty much the only arch that doesn't have 1.5 keyword but thanks to frequent poking, things should change pretty soon - 1.3 and 1.4 will get p.masked as soon as alpha and arm stabilize 1.5.3, - 1.3 will get treecleaned during the summer, 1.4 maybe a bit later... - the X11 overlay now has support for the nouveau driver and Gallium (thanks to a few external but essential contributors) Medium term : - libxcb 1.2 will be moved to portage once we figure out a sane way to handle the disappearance of libxcb-x11.so. For those who haven't heard or seen what happens during the upgrade, let's just say that the upgrade from expat 1.95 to 2.0 was a walk in the park compared to this. - continue cleaning up useless libs and protos Longer term : - major Docs overhaul, what we have now is a complete mess. Any help with this is greatly appreciated. See [1] for a short todo list. - try to keep up with upstream X, even if it means upsetting some users. Actually forcing folks to upgrade to 1.5 has been very beneficial, a lot of bugs were uncovered and reported upstream. Intel Driver Status Update - 2.6.3 is the current stable - 2.7.0 is still p.masked, 2.7.1 will likely go in ~arch when it's out - The next stable driver will probably be 2.8 once xorg-server 1.6 is in portage and deemed stable enough. - The upcoming 2.8 branch will have a lot less code and options (no more DRI1, XAA, EXA, ...), making it easier to maintain and to use. Cheers, Rémi
Re: [gentoo-dev] Project summaries - KDE team sumary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Faulhammer wrote:
> > Hi,
> >
> > any project lead/member can post an answer to this mail for a status
> > report:
> >
Hi.
Gentoo KDE team status report.
Current:
- We have a Lead again (me). It happened on FOSDEM, so it might have
been related to some "substance abuse" ;-)
- We have a strong team again full of new "blood" and are back in the
game - we can take more people, but we're able to keep up with the
work.
- Resumed our regular meeting schedule - 3rd Thursday of the month at
19H00 UTC on #gentoo-kde channel of the freenode IRC network.
- KDE-3.5.9 (stable) and 3.5.10 (testing) in the tree.
- KDE-4.2.3 (testing) in the tree.
- KDE-4.3 snapshots in the kde-testing overlay.
- KDE-4.3 live (4.2.) in the kde-testing overlay.
- KDE live () in the kde-testing overlay.
Soon:
- We're in the final stages to get updated KDE3 eclasses (currently in
kde-crazy overlay) into the tree. These eclasses move all misc apps
under the /usr/kde/3.5 prefix (to fix the colisions with KDE4 apps and
to fix prefix issues for KDE-3 apps).
- After we move the eclasses we'll ask to get KDE-3.5.10 marked stable.
This means the end of the support for mono ebuilds. Anyone using them
will have to switch to the split ebuilds.
- After getting this done, we can finally get KDE-4.X marked stable. We
hope to get all this done in the next 2 months.
How to help:
Although we have a fully staffed team now, we can always take more help.
If anyone is interested in the Gentoo KDE project and wants more info,
start by checking our page [1] and our overlays [2] [3]. We try to keep
some Docs in the kde-testing overlay [4] including some docs on how to
contribute and what needs to be done. Also, we still have a *few* open
bugs [5].
{1[ - http://www.gentoo.org/proj/en/desktop/kde/
[2] - http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary
[3] - http://git.overlays.gentoo.org/gitweb/?p=proj/kde-crazy.git;a=summary
[4] -
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=Documentation;h=92d10c3f9de2a22c5755a6fe746dfd5e75d7e044;hb=master
[5] - http://tinyurl.com/kdebugs1
P.S. - Working with the Gentoo KDE team and getting access to the
overlays is one way to get involved with Gentoo and might set you up in
the road to become a Gentoo Dev - we have quite a few people around to
proof it ;-)
- -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoG/jwACgkQcAWygvVEyAJzaACeP9u1zPQDf35ftPBYzIk2S7Ay
SCUAnjiU8D8qMVh/atyd31gZc5gwLZSs
=OE8O
-END PGP SIGNATURE-
Re: [gentoo-dev] Project summaries - Java & Recruiters
Christian Faulhammer wrote: > Hi, > > any project lead/member can post an answer to this mail for a status > report: > Java: - Too much stuff in overlays - Beat caster with a stick - Need more people to maintain our hundreds of packages - Critical pkgs do have designated maintainers - Beat all members with a stick so that they remember to show up for monthly meetings Recruiters: - pva and keytoaster can handle the current load - more people doesn't hurt but no active need to recruit more - the quizzes could use an overhaul Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project summaries - Alpha Arch Team
Robert Buchholz wrote: > Note that we have a Summer of Code student this year who is working on a > project to gather both hardware and software statistics from Gentoo > users. If you have any special requirements for your platform, I am > sure he has open ears. No need to invent two wheels at the same time. Yes, I'm all ears :-) Sebastian
Re: [gentoo-dev] Project summaries - Alpha Arch Team
On Wednesday 06 May 2009, Tobias Klausmann wrote: > I've been toying with the idea of offering something akin to > Debians popularity contest tool. Some people are rather > uncomfortable with data gathering tools that send stuff to some > strangers, so I don't know how well it would work. I list this > idea here, since I have just about no idea what actual alpha > hardware is used with Gentoo out there. Knowing which packages > are actually *used* (instead of just being stabilized for the > heck of it) would be nice. Added benefit of that would be that > users helping with testing would reduce workload. Hi Tobias, a late Happy Birthday from my side first. Note that we have a Summer of Code student this year who is working on a project to gather both hardware and software statistics from Gentoo users. If you have any special requirements for your platform, I am sure he has open ears. No need to invent two wheels at the same time. I'm putting Sebastian in CC directly, if you are looking for the project mentor, that is me. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Project summaries
> Future projects: > revdep-rebuild support for mono! > AOT support > Getting Mono tests to not fail in Sandbox. > Reducing the bus-factor. I have too much of this stuff in my head. I > should write docs... Later. Add to your todo: Making mono working on KDE4. It has bindings, but i dont have guts for testing nor making it work ;] signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Project summaries
On Wed, 6 May 2009 08:49:53 +0200 Christian Faulhammer wrote: > Hi, > > any project lead/member can post an answer to this mail for a status > report: Gentoo .NET progress Currently doing good. Nothing much to report. Everything is shiny and well-oiled. SVN ebuilds of trunk and branches were recently committed to the main tree, which will help when people report bugs. Generally trying to maintain as little distance between the main tree and the overlay as possible, so user feedback can be utilized most efficiently. ~arch is really the testing branch for Mono packages, IOW, but I try to fix bugs real quick when they're reported so most of you never notice they were there. Cool new apps which everyone should be using: Tasque for managing your everyday scheduling needs. Monsoon shiny bittorrent client Bareftp easy and accessible ftp client Cool old apps which everyone should be using: Tomboy notetaking application Banshee the best media-player out there Beagle desktop search Gnome-DoLOOK! SHINY! And of course mod_mono, for your ASP.NET needs. What we need: People who care about portable.NET enough to make it great. People who use the ASP.NET features. I can probably debug it for you, but if there's a bug in mod_mono, I won't discover it before you do. Notable successes: Bumping Mono-2.4 before Novell :-) Shaving bugs assigned to dot...@gentoo.org down to a reasonable level. Attracting users to Gentoo through our .NET offering. Future projects: revdep-rebuild support for mono! AOT support Getting Mono tests to not fail in Sandbox. Reducing the bus-factor. I have too much of this stuff in my head. I should write docs... Later.
Re: [gentoo-dev] Project summaries - Alpha Arch Team
Hi! So where are we at with alpha currently? Xorg-1.5 As some of you know, xorg-1.5 abandoned the "classic" way of interfacing with PCI and AGP cards in favor of using libpciaccess. That, in turn expects support from the kernel in the form of /sys/devicesresourceN files. Unfortunately, alpha until recently hat no support for those PCI resources (which is partly due to the way alpha IO space is structured and partly due to a crucial extension not being available on old Alphas (older than EV5). As such, we weren't able to keyword or stabilize Xorg-1.5 until recently, when 2.6.30-rc* saw support finally being added. Naturally, packages depending on >=xorg-1.5 had to be held off, too. The -rc kernels are keyworded ~alpha so people can test. So far, -rc3 and rc4 are looking good, so we will keyword xorg and deps soon (I'm aiming for this weekend) and if all goes well, we will have it stable, soon. Note that this will mean that people with EV4-Alphas will *not* be able to use Xorg-1.5 just now. I feel that those machines are so slow that very few will run X11 anyway, if there are Gentoo installations on those to start with. Glibc/Toolchain --- Glibc has had a bug for ages (regarding ceil() and friends, bug number 264335) which should really be fixed. Upstream is umm.. their usual selves about it. On top, a patch for fdatasync() (bug 264336) is available which upstream... well, you get it. Workload Currently, the alpha arch team consists of me (the nominal lead) and armin76 who helps a lot with getting stable request answered in a timely manner. Also, we're in the process of recruiting mattst88 as an arch tester. He's currently deep in exam-land at university, so the process is on hold for now. Users/Community --- Aside from those on the team and one or two other devs, I've had little to no direct feedback from Gentoo alpha users. I try to write about Alpha regularly on my blog (available on the planet) and I'm easily reachable as Blackb|rd on Freenode (#gentoo-alpha, naturally). I've been toying with the idea of offering something akin to Debians popularity contest tool. Some people are rather uncomfortable with data gathering tools that send stuff to some strangers, so I don't know how well it would work. I list this idea here, since I have just about no idea what actual alpha hardware is used with Gentoo out there. Knowing which packages are actually *used* (instead of just being stabilized for the heck of it) would be nice. Added benefit of that would be that users helping with testing would reduce workload. In essence: we're busy and I'd love to get more feedback what people (both users and devs) think we could do better, or more/less of. Regards, Tobias, who turned 42 in octal today -- The only problem with troubleshooting is that sometimes, trouble shoots back.
[gentoo-dev] Project summaries
Hi, any project lead/member can post an answer to this mail for a status report: Gentoo Lisp in general: We are working on all our problems, but some sub-projects are a bit understaffed (e.g. Common Lisp, because pchrist is away for a year), while Scheme is in good shape but has only one active developer at the moment. We get along, but help is always needed. All our overlays are well maintained and an active playground whose changes make it into the tree eventually. Project members can tell more about their field, I guess. http://www.gentoo.org/proj/en/lisp/index.xml Gentoo GNU Emacs: We are two people (ulm and myself), which handle the low bug load. In the last two years we revamped the tree and created some interesting things for Emacs users and eased our development work. We are mostly in maintenance-mode because our plans are done in general: * A developer guide how to maintain GNU Emacs and packages * Documentation of the eclasses * Eselect module to use one of the up to four GNU Emacs versions installed in parallel * app-emacs/gentoo-syntax for ebuild writers * small tools (emacs-updater) to ease use of Emacs * Push a policy on packages that is flexible and easy to use * Create test plans for packages, so architecture teams know how to test the package (some are still missing) * Keyword (x86 and amd64 are mandatory) and stabilisation We still miss: * A user-guide, where a draft from a user is available, but needs some polishing. * ulm can tell more http://www.gentoo.org/proj/en/lisp/emacs/index.xml XEmacs: graaff is the lone wolf here and because upstream development of XEmacs is not really on fire, he has not too much to do, I think. He introduced eclasses in a similar way as the GNU Emacs team. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
