[gentoo-dev] Projects and subproject status
Luca Barbato
going to do?"
Please project leaders try to reply in short.
About the stuff I'm involved:
Are we fine?
media
- gfx : nothing much under the sun, bumping stuff here and there.
- video: getting ready for the new ffmpeg and the applications we'll
have to patch.
What are we going to do:
media
- gfx : probably checking that stuff is getting up to date more often.
- video: Hopefully nothing much beside trying to give the best and
freshest snapshots from the repository you started to know (mplayer,
ffmpeg, xine, vlc...Hi Diego =)) and probably we'll have to handle some
pretty new stuff related to heterogeneous cores (CELL, CUDA) if what is
brewing right now gets more stable. We'll probably need more help from
the toolchain people to get some stuff building sanely.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gento...@lists.gentoo.org mailing list
Markus Ullmann
> Are we fine?
>
lcd : G15 in good shape, no major issues anywhere
ldap : openldap works good, nss_ldap has some issues here and there
net-irc : some minor issues with dead-upstream apps or apps breaking
their own configs but nothing too serious
net-mon : behind on some packages due to only 3 people taking care,
could use more hands to help maintaining
> What are we going to do:
lcd : nothing major atm
ldap : openldap 2.4 in the queue, yet needs more work to be safe
net-irc : nothing big, just some minor bumps here and there
net-mon : just working through bugs, some are hard to reproduce
so may take a bit to be resolved finally
Greetz
-Jokey
Diego 'Flameeyes' Pettenò
> - video: Hopefully nothing much beside trying to give the best and
> freshest snapshots from the repository you started to know (mplayer,
> ffmpeg, xine, vlc...Hi Diego =))
I'm involved just in one and a half of those ;)
As for me, I mostly handle PAM (solo as usual).
Current status: PAM 0.99 is stable on all architectures beside one,
which means that PAM maintenance should be quite easier. It has been a
few months till last release so the water is also quite calm. The
upgrade was smooth for most people up to now, hopefully the
documentation on that will suffice.
Future plans: I hope to be able to complete the developers'
documentation, it's mostly a matter of finding time to work on it again,
probably I won't be able to make it before February, but I count on
writing something starting mid-february.
And for what concerns PulseAudio:
Current status: 0.9.8 is in tree for a while but contains a few new
features that should be tested well before marking it stable, so 0.9.7
is the current candidate. The new init script using Baselayout 2/OpenRC
functionalities is well tested at this point and mostly waiting for
OpenRC to enter ~arch.
Future plans: again not before mid-february I'll see to write some user
documentation about PulseAudio, like a Gentoo-specific Perfect Setup, to
integrate the generic documentation available on PulseAudio's wiki.
As for other misc stuff I maintain, I don't know exactly what's left,
but you can easily see what I'm doing on the blog :P
--
Diego "Flameeyes" Pettenò
http://farragut.flameeyes.is-a-geek.org/
Fabian Groffen
> Here is a list of interesting questions: "Are we fine?" "What are we
> going to do?"
>
> Please project leaders try to reply in short.
Gentoo/Alt:Prefix
> Are we fine?
Sure.
- reached >10% coverage/replication of the gentoo-x86 tree
- convinced two contributors to become Gentoo ppl
- attracted more "big players"
- extended our arch.list
- brought Portage Prefix branch fully in sync with trunk
- rough Prefix binpkg support (chpathtool, via tinderbox.dev.g.o)
- enabled Java (Sun, Diablo, (Apple/Soylatte)), Haskell (GHC) in Prefix
- mostly automated tree syncing, to easily stay up-to-date
> What are we going to do:
Just continue.
- try to make cross-compiling/building with target prefix fully working
- sort out the 64-bits targets with their multilib-hell forced upon us
- add more arches, {net,open}bsd ones being worked on
- work out support for bootstrapping from a binhost
- hope we can get an rsync tree with metadata generated (get faster!)
- try to eliminate python as it usually doesn't compile (will fail)
- try to convince more people (you know who you are)
- finish writing of the stupid glep
- add more packages/try to close all package request bugs
- think about privileged installs
- get baselayout fully ported (support for runscripts)
- (maybe) think about multi-prefix (could solve the FreeBSD GNU conflict)
- try not to kill overlays.g.o
- seek cooperation with "Gentoo upstreams" where appropriate (part of
the slight maturing phase)
- try to get all the other companies we know they use us, to post
some testimony like
http://article.gmane.org/gmane.linux.gentoo.alt/3308 :) (wishful
thinking)
- maybe invest some time to get repoman's SVN support patch acceptable
for the trunk (not much benefit for us at the moment, though)
- (most probably) go crazy
--
Fabian Groffen
Gentoo on a different level
--
gento...@lists.gentoo.org mailing list
Fabian Groffen
> going to do?"
GNUstep
> Are we fine?
I'd say thanks to voyageur (much kudos to the guy) GNUstep is back where
it should be within Gentoo and up-to-date. Eclass changes, package
changes, all just got better.
> What are we going to do:
Probably trying to keep it up-to-date like it is right now, and try to
be the best distro for GNUstep users. Of course we'll hope that Etoile
becomes less buggy and more usable.
David Shakaryan
> Please project leaders try to reply in short.
> Are we fine?
We should be. The next answer should indicate where we can use some
improvement. As for the GNUstep packages, I'm not too sure what the
status is, but bugzilla doesn't reveal anything major.
> What are we going to do:
- Update FVWM and fix the ~5 bugs related to it.
- Fix a few miscellaneous fluxbox apps.
- Punt a couple of old, broken packages.
- Continue keeping things up to date.
--
David Shakaryan
--
gento...@lists.gentoo.org mailing list
Petteri Räty
> Here is a list of interesting questions: "Are we fine?" "What are we
> going to do?"
Java
>
> Please project leaders try to reply in short.
>
> Are we fine?
Quite okay. Slowly recruiting new people and doing the usual
maintenance. Could always use more active people of course.
>
> What are we going to do:
>
- Get the remaining Generation 1 stuff out of the tree (not much left)
- Start using virtuals more
- Eclass cleanup and new make our setup even more automatic
Regards,
Petteri
Samuli Suominen
Luca Barbato <lu_...@gentoo.org> wrote:
> Here is a list of interesting questions: "Are we fine?" "What are we
> going to do?"
>
> Please project leaders try to reply in short.
xfce (has no lead, it's angelos, welp or me) - we are good, few ~minor
bugs, everything up to date
treecleaners - needs more developers (please) to review & save the stuff
that is getting removed so it doesn't end up as a tool that few devs
can use to punt stuff they want, but others use(!)
> - gfx : nothing much under the sun, bumping stuff here and there.
I just joined gfx, will try to contribute some more.
- drac
--
gento...@lists.gentoo.org mailing list
Christian Faulhammer
Hi,
CCing gentoo-lisp mailing list.
Luca Barbato <lu_...@gentoo.org>:
> Please project leaders try to reply in short.
Though Emacs project (subproject of Lisp) has no official leader, I
speak up as senior dev. :)
> Are we fine?
XEmacs:
I cannot tell much, but graaff seems to have closed most of the severe
bugs and worked on having more/bette eclasses for the app-xemacs
category.
GNU Emacs:
* We took care of nearly all incoming bugs and punched ones
still sitting around
* Started keywording all packages with stable x86 and amd64 (majority
is done)
* Split up of eselect-ctags and eselect-emacs so them Vim wheenies
stop crying (just after Portage was able to handle needed upgrade path
correctly)
* Files which enable additional packages from app-emacs category in
Emacs are now stored in /usr/share/emacs/site-lisp/site-gentoo.d/, with
full backwards compatability (fully transparent for non-aware users).
emacs-updater from eselec-emacs package can check if you still have
site files in the old location.
* Support for echangelog (by C-c C-a) in app-emacs/gentoo-syntax
* Man, we got so many test plans for our packages that arch teams
should be able to stabilise our packages in the blink of an eye.
* Fixed some more packages that were working but not in a good shape
regarding coding practice (Emacs and Ebuild)
> What are we going to do:
* Improve the tree further, though we are nearly done
* Bring some really handy packages into the tree from our overlay
* Improve gentoo-syntax to use the whole Gentoo toolchain for Ebuild
developers
V-Li
--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
Brent Baude
> Are we fine?
>
- The induction of the PS3 has helped us a lot. We have more users than
before. Great variance skill-wise amongst those users but interest
level is high. We need more folks on the dev team but otherwise we're
as healthy as we've ever been.
- Just put a ps3 dev profile into portage to begin moving towards our
longer term goals
- Lu_zero and I have added a couple of ps3 specific ebuilds into the
tree; previously were in the cell overlay
> What are we going to do:
>
- Anticipating gcc-4.3 and the love it is supposed to bring,
specifically cell optimizations.
- BAU
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Scanned with Copfilter Version 0.84beta3a (ProxSMTP 1.6)
AntiVirus: ClamAV 0.91.2/5451 - Wed Jan 9 03:07:04 2008
by Markus Madlener @ http://www.copfilter.org
--
gento...@lists.gentoo.org mailing list
Wulf C. Krueger
- KDE-related stuff
> Are we fine?
All in all, we're doing acceptably well, I'd say. In some areas, we're
doing really well.
I've recently mentored two new recruits, namely Ingmar "Ingmar"
Vanhassel and Bo "zlin" Andresen who will hopefully soon become new
members of the KDE herd. These new slav^H^H^H^Hhelpers ;) are both
great additions to the herd and will allow us to become more efficient
in the near future.
KDE 3: We're still fixing bugs but should soon be able to finally
stabilise 3.5.8. This took us much longer than I wanted it to but I'm
under heavy workload in real life and had to take some time off from
Gentoo.
We still have 3.5.5 in the tree but that's going to change once either
Carlo or myself will make ourselves remove those ebuilds. If we remove
them, this can lead to some breakage for a certain arch but they've
known for long enough now: http://bugs.gentoo.org/show_bug.cgi?id=188857
KDE 3 is pretty solid now apart from some bugs we're tackling along the way.
KDE 4: A core team consisting of volunteers from the KDE herd and
interested users (that's how tgurr, Ingmar and zlin got on board or
are going to get on board as devs. :-) ) as well as some help from
interested fellow devs is working on a new set of eclasses (going to
be submitted here very soon) and ebuilds (both monolithic and split
ebuilds; splits being the new default) for KDE 4.
KDE 4.0.0 will be released on January, 11th 2008, and if things keep
going like they do now we might be able to put all the stuff into
~arch on the release day.
I'm going to mail about this again in -core soon.
The excellent cooperation among the core team members and all others
involved in KDE4 in Gentoo is truly amazing and makes me really proud
to be a part of this effort. I'm happy and optimistic about things to
come if we manage to keep some of the drive we currently have.
--
Best regards, Wulf
Luca Barbato
>
> - Get the remaining Generation 1 stuff out of the tree (not much left)
> - Start using virtuals more
> - Eclass cleanup and new make our setup even more automatic
any plan/idea about icedtea? as a ppc user I'd love too see it in
portage ^^;
Carsten Lohrke
> going like they do now we might be able to put all the stuff into
> ~arch on the release day.
> I'm going to mail about this again in -core soon.
Unless you mean hard masked, I do object. The code base has too many issues
and is incomplete compared to KDE 3.5, so it's not ready to push it to the
regular ~arch user, yet.
Carsten
Chris Gianelloni
> Here is a list of interesting questions: "Are we fine?" "What are we
> going to do?"
>
> Please project leaders try to reply in short.
>
> About the stuff I'm involved:
>
> Are we fine?
GWN: The GWN is currently in a permanent state of hiatus. I have no
intentions on spending another minute working on the GWN. While many,
many improvements have been made in the processes for getting the
automated data, getting articles has been pulling teeth, at best. This
was taking me upwards of 12 hours a week, which was impacting the time I
had available to work on things like releases and my day job. As such,
the GWN is abandoned and will likely stay that way until someone steps
up and decides they're ready and willing to give up their lives to work
on this publication. Yes, I think switching to a monthly newsletter
would *help* the problem, but it still won't resolve it. The GWN needs
articles more than anything, and few people are submitting anything.
Release Engineering: We dropped the 2007.1 release due to many issues
which I won't go into here, since it really isn't appropriate at this
time. As such, we're deciding on what our plan is for 2008 and beyond.
We are working on finalizing the latest versions of genkernel/catalyst.
PR: Well, I'm not the lead here, but since the lead is AWOL, I guess
that I can give my input. This project is essentially dead. There are
a couple people who occasionally respond to user queries to the alias,
but otherwise, nothing is going on here. Nobody is really active. I
sent in some news about 2007.1 a few weeks back and nobody's posted
anything or even responded. I'd say the project is dead if we can't
even get out pertinent information like the cancellation of a release to
our users.
Trustees: Well, the Foundation no longer exists, legally, so it's pretty
obvious that things are not "fine" here.
> What are we going to do:
GWN: no clue, looks like nothing
RelEng: work on catalyst/genkernel, no further plans
PR: no clue, looks like nothing
Trustees: I retired as a Trustee since there's not much point without a
Foundation to run, leaving us with one (or possibly two) trustees.
--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer
Petteri Räty
> Petteri Räty wrote:
>> - Get the remaining Generation 1 stuff out of the tree (not much left)
>> - Start using virtuals more
>> - Eclass cleanup and new make our setup even more automatic
>
> any plan/idea about icedtea? as a ppc user I'd love too see it in
> portage ^^;
>
> lu
>
Well having it open source doesn't mean automatically ppc support but
there are people working on it.
Regards,
Petteri
Luca Barbato
> Well having it open source doesn't mean automatically ppc support but
> there are people working on it.
I'm quite aware about it I followed the improvement on this side since a
while even if I hadn't the time to try myself building it on ppc yet.
Luca Barbato
>> What are we going to do:
>
> GWN: no clue, looks like nothing
Well I hope there is somebody willing to at least try to get a minimal
gwn as new year kickoff out even just by summarizing this thread ^^;
> RelEng: work on catalyst/genkernel, no further plans
I'm looking forward to see the improved tools and hopefully get the in
system deps fixed as vapier just suggested/pointed.
> PR: no clue, looks like nothing
Maybe would be good check who is alive.
> Trustees: I retired as a Trustee since there's not much point without a
> Foundation to run, leaving us with one (or possibly two) trustees.
I guess this part requires discussion elsewhere since there isn't much
technical.
Pierre-Yves Rofes
Hash: SHA1
Luca Barbato a écrit :
> Here is a list of interesting questions: "Are we fine?" "What are we
> going to do?"
>
> Please project leaders try to reply in short.
>
Ok, technically I'm not security lead, but since I and rbu almost
completely handled the security team since 2 months, I think I can at
least give my opinions on what's going on.
> About the stuff I'm involved:
>
> Are we fine?
security:
Well, with an average of ~ 1 GLSA/day for November and December, things
are going a little bit better than some months ago. We still have too
many open bugs (~115),but we tend to be a little more reactive since we
now actively monitor the vendor-security mailing list plus the freshly
attributed CVE ids, so we're able to file bugs and get them corrected
before they go public. This also means arches security liaisons should
be prepared to get called more often from now on.
>
> What are we going to do:
>
Personally, I'd like that we become more regular for the GLSA releases,
instead of doing nothing for days then rushing to send 10 GLSAs in 2 days.
I'd also like to take care of the really old bugs, say, opened for at
least 6 months (~25 at the moment).
Don't know if we'll manage to do it, but at least we'll try.
This was a (very) short reply, sec team members are of course
welcome to complete.
- --
Pierre-Yves Rofes
Gentoo Linux Security Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHhVS1uhJ+ozIKI5gRAqbnAJ9URJQ2fMFdjrpaER1dKF+ws4VDQQCdHZ98
2rCq9l3JGrxfSXZNttN40ok=
=5N0K
-----END PGP SIGNATURE-----
--
gento...@lists.gentoo.org mailing list
Paul Varner
On Mon, 2008-01-07 at 22:31 +0100, Luca Barbato wrote:
> going to do?"
>
> Please project leaders try to reply in short.
tools-portage:
Are we fine? The short answer is no. We need more developers.
Unfortunately, real life work is consuming all of my time and what free
time is left is going to my family. mpagano has started to step up and
work bugs, but we definitely need more help. I am on email and IRC so I
can answer questions and work with any developer who would like to step
up and help (even temporarily).
Marius (genone) stepped down as team lead on December 3rd and asked for
help for the team at that time. I have not seen any reponses to that
request.
What are we going to do?
Due to lack of time and participation, I currently don't have a good
answer for that.
On my short list is to get revdep-rebuild fixed. The current state
leaves much to be desired and while it works for most people, it is
definitely a visible turn off for people when it fails.
Regards,
Paul
--
gento...@lists.gentoo.org mailing list
Ryan Hill
> Here is a list of interesting questions: "Are we fine?" "What are we
> going to do?"
>
> Please project leaders try to reply in short.
[ wxWidgets ] (i'm not the lead but i don't think leio will mind)
Done:
We got 2.8 into the tree (yay). After a few bug reports that were
mostly silliness on my part, things have mostly been smooth sailing.
Hopefully it's working out for everyone.
To Do:
I have a couple people interested in ports other than wxGTK (eg.
wxMac). I'd like to start by separating wxBase into its own package and
get support for building against an external wxBase into upstream. I
haven't talked to upstream about this yet and they may violently
disagree with this approach so all this is highly tentative. I have no
idea what form other ports in portage will take at the moment.
Work on upcoming releases (2.10(?)/3.0) will begin when said releases
are closer to.. er.. release.
[ gcc-porting ] (again not the lead but I don't think vapier will mind)
Done:
The usual.
To Do:
I've been working on getting the tree ready for GCC 4.3 but it's been
slow going. 4.3 is a hell of a lot more disruptive than 4.2 was. There
is a preliminary porting document posted at
http://people.redhat.com/~bkoz/porting_to_gcc43.html which outlines most
of the major issues if people are interested. Right now I almost have
Gnome building while KDE is a bit further behind just due to the most
commonly encountered 4.3 incompatibilities being in C++ code (KDE itself
has been fine, most of the problems are in the dependencies). Anyone
wishing to follow this progress can checkout my overlay via layman and
subscribe to Bug #198121. (I also have svn GCC ebuilds in my overlay.
They work on 64bit targets which i think the ones in the toolchain
overlay have trouble with (?).)
[ fonts ] (hey, i do run this one!)
Done:
Version bumping. Random fixing. Thanks to pva the eclass now
handles conf files with spaces in their names. :) Thanks to cardoe we
have an awesome eselect module for tweaking said conf files. :) I think
all of our major bugs have been fixed.
To Do:
We've gotten a couple more ppl so things should go a bit smoother.
There are a crapload of font ebuild requests in bugzilla I'd like to
sort through. (I'm not adding every request to the tree; fonts will be
considered based on quality, coverage, license, etc.) I'd like to bring
our font selection up to the level of other mainstream distros, as well
as review our defaults to try and provide a better out-of-the-box
experience for >=2008.x. fontconfig-2.5 helps with this and I'm
planning on stabilizing it soon.
--
fonts, by design, by neglect
gcc-porting, for a fact or just for effect
wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
--
gento...@lists.gentoo.org mailing list
Josh Saddler
> Here is a list of interesting questions: "Are we fine?" "What are we
> going to do?"
Documentation
(Note: I'm not the project lead, but neysx isn't on the list, nor does
he send status updates, so I hope he and the rest of the project won't mind.
> Are we fine?
Sure, why not. The pace of new bugs has slowed down, which is good, as
it allows for, uh, existing bugs to get fixed?
Over the last couple of months, some GDP devs besides me have been
making commits, which is a nice change of pace from how the year had
been previously. :) (I can take a vacation, whoo!)
Sure, we have a few bugs that are two or three (or even four) years old,
but who doesn't?
We could always use more translators though. We have several dead
languages, some of which used to be pretty big.
> What are we going to do:
The handbooks for the upcoming release are almost ready. Our release
plans have changed slightly; still coordinating with releng. We'll get
'em finished up and delivered . . . at some point. Promise.
On down the road, you can expect the usual maintenance of existing
world-class docs. I hope to get more patches submitted[1] against our
ldap guide[2] so that it can be made an official doc once again.
I'm sure we'll be seeing new documentation this year; there's always at
least a few new guides per year. You have any suggestions on new docs
you'd like to see, feel free to send 'em my way. Or open a bug if you
have actual content already written. ;)
[1] http://bugs.gentoo.org/show_bug.cgi?id=176075
[2] http://www.gentoo.org/doc/en/ldap-howto.xml
Gunnar Wrobel
> Here is a list of interesting questions: "Are we fine?" "What are we
> going to do?"
>
> Please project leaders try to reply in short.
>
> About the stuff I'm involved:
web-apps
>
> Are we fine?
webapps is more or less fine. We have several people in the herd
maintaining their favourite webapps and rl03 and me are handling the
rest of them. With rl03 really busy at the moment I'm lagging a little
bit behind but have been able so far to keep the bug list on a small
level.
I was not able to continue development on webapp-config for a while
though.
> What are we going to do:
Continue caring for webapps and hopefully closing more bugs than new
ones come in during the next months.
And then finally getting back to the next version of webapp-config.
Cheers,
Gunnar
--
Gunnar Wrobel Gentoo Developer
__________________C_o_n_t_a_c_t__________________
Mail: wro...@gentoo.org
WWW: http://www.gunnarwrobel.de
IRC: #gentoo-web at freenode.org
_________________________________________________
--
gento...@lists.gentoo.org mailing list
George Shapovalov
Monday, 7. January 2008, Luca Barbato Ви написали:
> Are we fine?
>
More or less, I'd say Ok with the stuff we have in the tree already. Need more
devs (who does not? :)) that's for sure. Right now we are ~10 people for 300
packages and there are another ~300+ in bugzilla. Which immediately leads to
recruiting. Right now we train two more devs, but I'd say we can swallow
pretty much anybody who comes in our direction :) (especially considering a
rather special nature of our packages). For the most part we are reruiting
active users who already "proved" themselves (e.g. by participating in
science overlay), but we may add a standing recruitment request on that
recruitment page.
> What are we going to do:
Mostly keep things running. Not much more can be done with this manpower
anyway. We already perfromed a split in terms of categories and herds,
although this is getting revisited once in a while as we get more people and
packages (there are still a few bugs open about new herds that were not
inalized I believe).
George
--
gento...@lists.gentoo.org mailing list
"José Luis Rivero (yoswink)"
Speaking for Gentoo/Alpha Arch Team (ferdy is the lead but I used to be
the status report guy):
Luca Barbato escribió:
>
> Are we fine?
>
I would say: yes.
Reasons:
- General keywording is just fine.
- Security bugs are done in a reasonable period of time.
- We have a new and shiny developer machine.
- Kernel and toolchain are nearly up to date
(some bugs in latest versions, as usual).
- Arch Testing program has worked quite well.
>
> What are we going to do:
>
- First of all, keep things working (this could sound easy but being
an alpha port ... you never knows).
- New developer (Tobias) is ready to join the forces. (bug #196948)
- First tests to bring java via gcj are done.
(http://www.nabble.com/Java-gcj-in-Gentoo-Alpha-to12131495.html)
- Look to create a binpkg repo.
- Continue the arch testing program and try to recruit fresh blood.
Alpha Arch Team provides 'regular' status report so historical info
about the port status can be found in our subproject page:
http://www.gentoo.org/proj/en/base/alpha/status/index.xml
That's all from the alpha world.
Enjoy.
--
Jose Luis Rivero <yos...@gentoo.org>
Gentoo/Doc Gentoo/Alpha
--
gento...@lists.gentoo.org mailing list
Rémi Cardona
Luca Barbato a écrit :
> Are we fine?
Mostly, Gnome packages these days tend to be more stable, pushing the
complexity (and breakages) lower down into the stack (HAL, PolicyKit)
The rest of team is steadily adding Gnome 2.20.3 packages to the tree.
We are somewhat behind on gtk+ mostly due to documentation building
issues. But nothing major there as it's only a bugfix releases thing.
> What are we going to do:
For Gnome 2.22, I promised the rest of the team I'd be putting the
ebuilds into portage earlier. The target is Gnome 2.21.90 which is due
at the end of January.
So as we bump our ebuilds for this release, we'll put them in portage
(hard masked). That should help us unmask Gnome 2.22 much faster.
We're also waiting for the next stable release of portage so that we can
fix one of our long standing eclass bugs, which should improve all
gtk-using ebuilds : https://bugs.gentoo.org/show_bug.cgi?id=155993
Rémi
--
gento...@lists.gentoo.org mailing list
George Shapovalov
Monday, 7. January 2008, Luca Barbato Ви написали:
> Are we fine?
PL:
Ok as it is but could be better. It was concieved, among other things, to
consolidate resources and, possibly, do discussions of common things for some
of the languages we have support for (one even almost happend in bug
#151343), however right now it pretty much only serves as a placeholder for
specific resources and docs for some of them. Even there there are only Ada
and Haskell, while we have many more..
Ada:
Quite good actually. I completed all the outstanding parts of the transition
to multiple compilers. We already have one Ada-2005 compiler in the tree.
Another one, - gnat-gcc-4.3 will be coming when gcc-4.3 is finally released.
> What are we going to do:
PL:
not much at present - it is there as it is, however if there is interest we
could expand it, or at least get a bit more organization in now separate but
seemengly related packages.
Ada:
Complete transition, update libs, regular maintenance, new packages - pretty
much regular stuff..
Ferris McCormick
1. Are we fine?
Qualified yes. We are understaffed and at some point burn out is going
to catch up with us. At the moment we seem to be keeping up, largely
because of the superhuman efforts of Raúl Porcel (armin76). Also
because of his and agaffney's efforts, we are on track for release.
We have a couple open lead positions which I would like to fill, but I
guess that won't happen until I spend some time on it. See the sparc
project pages if you are interested in joining a fun, dynamic
project. :)
2. What are we going to do?
- Recruit, I hope. Especially AT's on path leading to developer
status.
- Otherwise, pretty much what we are doing. As an architecture
project, our primary goal is to keep sparc as current and stable as
possible, and I believe we are working to do just that.
Regards,
Ferris (sparc lead)
--
Ferris McCormick (P44646, MI) <fmc...@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc, Userrel)
Duncan
excerpted below, on Wed, 09 Jan 2008 22:41:55 +0200:
> Luca Barbato kirjoitti:
>> Petteri Räty wrote:
>>> [Java]
>>
>> any plan/idea about icedtea? as a ppc user I'd love[]
>>
> Well having it open source doesn't mean automatically ppc support but
> there are people working on it.
As a (non-ppc, amd64 FWIW) libreware user, I too am happy to see
someone's working on icedtea. I'd love to have a real/working Java as a
viable option once again. Not demanding as I'm very aware I'm not doing
the work, just wondering, and appreciating that it's even possible, now,
and all the work people both upstream and Gentoo are putting into it.
ETA? At least order of magnitude (weeks, months, years, hopefully not
decades! =8^)? I'm not afraid of overlays.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
gento...@lists.gentoo.org mailing list
William L. Thomson Jr.
On Thu, 2008-01-10 at 14:06 +0000, Duncan wrote:
> Petteri Räty <betel...@gentoo.org> posted 47853193...@gentoo.org,
> excerpted below, on Wed, 09 Jan 2008 22:41:55 +0200:
>
> > Luca Barbato kirjoitti:
> >> Petteri Räty wrote:
> >>> [Java]
> >>
> >> any plan/idea about icedtea? as a ppc user I'd love[]
> >>
> > Well having it open source doesn't mean automatically ppc support but
> > there are people working on it.
>
> As a (non-ppc, amd64 FWIW) libreware user, I too am happy to see
> someone's working on icedtea. I'd love to have a real/working Java as a
> viable option once again. Not demanding as I'm very aware I'm not doing
> the work, just wondering, and appreciating that it's even possible, now,
> and all the work people both upstream and Gentoo are putting into it.
>
> ETA? At least order of magnitude (weeks, months, years, hopefully not
> decades! =8^)? I'm not afraid of overlays.
No clue on ETA. I will take a peek/poke at it. I need to double check,
but pretty sure icedtea might still need sun-jdk to build. Even if that
is not the case, things like the plugin and other non-open aspects
aren't available yet in icedtea. So there is still much left to be
desired.
I am pretty sure due to the need either for build or run of sun-jdk we
aren't really motivated to do anything special with icedtea at this
time. Really doesn't allow us to do anything more than we can now with
openjdk. Sure some more free tools are used to build instead of entirely
using sun-jdk. But it's not complete, so leaves stuff to be desired.
http://icedtea.classpath.org/hg/icedtea/file/6cb15624ed1d/README
Not to burst your bubble or pee in your corn flakes. But I will see what
I can do to slowly start making an effort to package it. Love to see a
contributor or someone step up there. As over all maintenance of openjdk
is ALLOT atm due to weekly releases :(
--
William L. Thomson Jr.
Gentoo/Java
Anant Narayanan
Sorry for the thread hijack, but...
> GWN: The GWN is currently in a permanent state of hiatus. I have no
> intentions on spending another minute working on the GWN. While many,
> many improvements have been made in the processes for getting the
> automated data, getting articles has been pulling teeth, at best.
> This
> was taking me upwards of 12 hours a week, which was impacting the
> time I
> had available to work on things like releases and my day job. As
> such,
> the GWN is abandoned and will likely stay that way until someone steps
> up and decides they're ready and willing to give up their lives to
> work
> on this publication. Yes, I think switching to a monthly newsletter
> would *help* the problem, but it still won't resolve it. The GWN
> needs
> articles more than anything, and few people are submitting anything.
If nobody has a problem with making the GWN a GMN (Monthly
newsletter), then I am willing to volunteer to get this project back
on track. Even if few people actually submit anything, I think there
is enough activity going on this list, the planet and -commits to fill
up a newsletter every month. And I'm willing to invest 12, even 15,
hours a month to get this thing rolling again.
Cheers,
Anant
--
gento...@lists.gentoo.org mailing list
Duncan
1199982428.7...@wlt.obsidian-studios.com, excerpted below, on
Thu, 10 Jan 2008 11:27:08 -0500:
> I need to double check,
> but pretty sure icedtea might still need sun-jdk to build. Even if that
> is not the case, things like the plugin and other non-open aspects
> aren't available yet in icedtea. So there is still much left to be
> desired.
Good point. Thanks. Hopefully the predictions that it's fully free
sometime later this year are correct, tho, and naturally, I'd find it
useful to have a Gentoo ebuild for it available at that time. Since the
topic came up, I thought I'd at least throw in that you've got one eager
consumer waiting for that day. =8^)
Alec Warner
> Here is a list of interesting questions: "Are we fine?" "What are we
> going to do?"
>
> Please project leaders try to reply in short.
>
> About the stuff I'm involved:
>
>
GLEPS -
Thanks to nesyx I rewrote the glep index to use new tables and XML
data so upating status was less of a pain (editing html or 'guidexml'
sucks).
We have some new gleps and I've tried to be a bit more responsive
(grant has been busy lately). I need to take on a bigger role here,
but gleps 54 and 55 were edited recently. There are probably more
status updates to do and I have to get this silly html template
updated and past the cvs filter.
> What are we going to do:
GLEPS -
Edit old gleps for language and consistency. hopefully people will write more.
-Alec
--
gento...@lists.gentoo.org mailing list
Christian Faulhammer
> If nobody has a problem with making the GWN a GMN (Monthly
> newsletter), then I am willing to volunteer to get this project back
> on track.
Fine, as I do for some time now I submit weekly summaries of
activities on Planet Gentoo...so be assured I will deliver that
material to the GMN, too.
Marius Mauch
Current status:
The portage project is mostly fine, though we've missed my original
plan to release the first 2.2 test versions last year, mostly because
of lack of time on my part. I hope we can fix that within the next two
or three months.
As Paul has already mentioned, the tools-portage subproject definitely
needs more people, or we may just dissolve it completely (it has been a
one man show for some time already). Some people to help with
(technical) documentation would also be useful (manpages, docbook
stuff, ...)
Plans:
- release test versions of portage-2.2, see how all the new stuff works
in practice and adjust things if necessary
- help to fix external tools (including gentoolkit) and documentation to
fully support portage-2.2
- some ideas for the time after 2.2:
* merge gentoolkit into portage
* redesign some of the old APIs (dbapi, config) and implement new
ones (query framework)
* replace revdep-rebuild with a package set
* implement a new installed-package database
* new dep resolver (as always ;)
* new user interface(s)
* ...
Marius
--
gento...@lists.gentoo.org mailing list
Petteri Räty
>
> No clue on ETA. I will take a peek/poke at it. I need to double check,
> but pretty sure icedtea might still need sun-jdk to build. Even if that
> is not the case, things like the plugin and other non-open aspects
> aren't available yet in icedtea. So there is still much left to be
> desired.
>
The whole reason for icedtea to exist is to have a version of OpenJDK
that doesn't require sun-jdk to build. You can also have a plugin with
the use of gcjwebplugin.
Regards,
Petteri
William L. Thomson Jr.
On Thu, 2008-01-10 at 22:21 +0200, Petteri Räty wrote:
> William L. Thomson Jr. kirjoitti:
> >
> > No clue on ETA. I will take a peek/poke at it. I need to double check,
> > but pretty sure icedtea might still need sun-jdk to build. Even if that
> > is not the case, things like the plugin and other non-open aspects
> > aren't available yet in icedtea. So there is still much left to be
> > desired.
> >
>
> The whole reason for icedtea to exist is to have a version of OpenJDK
> that doesn't require sun-jdk to build.
Right but when we have discussed it in the past, the dep of sun-jdk was
the de-motivator. Pretty much per your words in a past August
meeting[1-2].
"(16:46:07) wltjr: I am clueless to it all, just picking up on tid bits, no clue on requirements
(16:46:16) wltjr: http://en.wikipedia.org/wiki/IcedTea_%28software%29
(16:46:21) Betelgeuse: icedtue builts just fine with Sun Java
(16:46:26) Betelgeuse: but that beats the point of icedtea
(16:46:31) wltjr: lol :)
(16:46:36) vladsharp: wltjr: the last time I checked, IcedTea? needed gcj working
(16:46:45) vladsharp: Betelgeuse: yes..
(16:46:56) Caster: sounds like geki's job :P
(16:47:10) Betelgeuse: eventually icedtea stuff should be merged back to OpenJDK proper
(16:47:19) Betelgeuse: so IcedTea? would never really make into main tree
(16:47:28) Betelgeuse: as such I am not interested in putting effort to packaging it
(16:47:38) Betelgeuse: but others feel free :)"
Granted I believe things have changed since, but are not 100%.
gcj is not even official maintained by any Gentoo Devs atm. No where
near close to being added to tree. Much less in the same overlay as
openjdk. Not that it's in bad shape, but there is no syncing or
collaboration there. But seems moot, as IcedTea should not require gcj
to build. If I am reading the upstream docs correctly[3].
> You can also have a plugin with the use of gcjwebplugin.
Even the plugin lacks allot of plugin functionality per the previous
link[3]. They claim basic support. Kinda makes me think about gnash wrt
to Flash there. Sure there is an open source Flash player plugin, but
can anyone really use it all the time? Not really, so not sure if
applets are the same with gcjwebplugin. I doubt one could use that in
all places a normal Java plugin would be used.
Not to mention gcjwebplugin is another project[4], not part of IcedTea.
They are just using it. I don't know if IcedTea is shipping it or is
available on it's own? Seems integration is still in progress[5]. If on
it's own, I don't believe there is a gcjwebplugin ebuild floating
around?
What about Java Webstart? Which is almost used more than the plugin on
the desktop these days, for some. Seems they are using another external
project there? But I can't find reference or mention, atm. Is that a
complete project as well? Not sure.
1. http://overlays.gentoo.org/proj/java/wiki/August_2007_Summary
2. http://overlays.gentoo.org/proj/java/wiki/August_2007_Meeting_Log
3. http://icedtea.classpath.org/hg/icedtea/file/6cb15624ed1d/README
4. http://www.nongnu.org/gcjwebplugin/
5. http://fedoraproject.org/wiki/Features/IcedTea#head-f4ea0ed1739c747de59e7b55d241cc8d9d574165
Petteri Räty
> near close to being added to tree. Much less in the same overlay as
> openjdk. Not that it's in bad shape, but there is no syncing or
> collaboration there. But seems moot, as IcedTea should not require gcj
> to build. If I am reading the upstream docs correctly[3].
>
IcedTea builds with any 1.5 JDK. So that includes both gcj and sun-jdk.
Regards,
Petteri
Donnie Berkholz
> - release test versions of portage-2.2, see how all the new stuff works
> in practice and adjust things if necessary
Could you start kicking out masked/unkeyworded snapshots? Release early,
release often, and all that jazz.
Thanks,
Donnie
--
gento...@lists.gentoo.org mailing list
Chris Gianelloni
> If nobody has a problem with making the GWN a GMN (Monthly
> newsletter), then I am willing to volunteer to get this project back
> on track. Even if few people actually submit anything, I think there
> is enough activity going on this list, the planet and -commits to fill
> up a newsletter every month. And I'm willing to invest 12, even 15,
> hours a month to get this thing rolling again.
That's great! I am afraid that it'll likely take you much longer than
you anticipate, as it took me that long every *week* when I was doing
it.
Some of the scripts would need to be updated to work on a monthly-basis
rather than weekly. Also, I still think that it would be good to
automate the scripts that run by putting them on infra somewhere and
having just the output mailed to gwn-feedback as it'll save a little bit
of time for the person doing the GWN and also it'll make sure you don't
forget to run it.
--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
William L. Thomson Jr.
On Thu, 2008-01-10 at 23:35 +0530, Anant Narayanan wrote:
>
> newsletter), then I am willing to volunteer to get this project back
> on track. Even if few people actually submit anything, I think there
> is enough activity going on this list, the planet and -commits to fill
> up a newsletter every month. And I'm willing to invest 12, even 15,
> hours a month to get this thing rolling again.
I can likely commit to one article a month. But it will likely need to
be reviewed by an editor, etc. Spelling, grammar, makes sense to
non-native English speakers ( proper English I am ghetto :) )
Weekly I could not commit to, but monthly I don't think squeezing out
one article a month will take to much of my time. I can likely spare
that and set it aside. Please let me know.
Ryan Hill
If you do, I can start doing package mask reports again. I stopped when
the GWN did since I didn't think it was very interesting to -dev readers
that see the individual announcements anyways.
Donnie Berkholz
> If you do, I can start doing package mask reports again. I stopped when
> the GWN did since I didn't think it was very interesting to -dev readers
> that see the individual announcements anyways.
Keep 'em coming to -dev-announce, at least. Without a GWN, that's a good
source for keeping up with things.
Ryan Hill
> On 17:51 Thu 10 Jan , Ryan Hill wrote:
>> If you do, I can start doing package mask reports again. I stopped when
>> the GWN did since I didn't think it was very interesting to -dev readers
>> that see the individual announcements anyways.
>
> Keep 'em coming to -dev-announce, at least. Without a GWN, that's a good
> source for keeping up with things.
Okay, but the ones i did send never did make it through to the list.
I'll try again.
Anant Narayanan
On 11-Jan-08, at 4:14 AM, Chris Gianelloni wrote:
> Some of the scripts would need to be updated to work on a monthly-
> basis
> rather than weekly. Also, I still think that it would be good to
> automate the scripts that run by putting them on infra somewhere and
> having just the output mailed to gwn-feedback as it'll save a little
> bit
> of time for the person doing the GWN and also it'll make sure you
> don't
> forget to run it.
Thanks Chris. I just went through the Gentoo Weekly News guide (which
is a little outdated, but still quite helpful). Are there any other
scripts other than glsa2gwn.py and bugs2gwn.py that need to be run?
I'll try and co-ordinate with infra to get them running automatically
on a monthly basis. Is there anything else I need to know?
A few points:
1) I'm going to create a sub-project called 'GMN' under the PR
project, which will supersede the GWN project.
2) I'm planning to get the first issue out by 21st of this month, and
subsequently on the third monday of every month.
3) Can we have email aliases g...@gentoo.org and gmn-...@gentoo.org
for purposes of this project? (It sounds silly to ask for feedback on
the GMN at gwn-fe...@gentoo.org)
4) Can we 'move' the gentoo-gwn mailing list to gentoo-gmn?
@Christian, William and Ryan:
Please do resume sending your articles as soon as I get the gmn email
alias setup. I'll get in touch with you shortly after the necessary
arrangements have been made.
Any suggestions/tips/comments on the new venture, are of course, more
than welcome.
Wulf C. Krueger
> > KDE 4.0.0 will be released on January, 11th 2008, and if things keep
> > going like they do now we might be able to put all the stuff into
> > ~arch on the release day.
We're not going to make it today. (Which is quite obvious since we haven't
submitted the eclasses yet. :-) )
> Unless you mean hard masked, I do object.
Thanks for your advice.
> The code base has too many issues and is incomplete compared to
> KDE 3.5, so it's not ready to push it to the regular ~arch user, yet.
I didn't mean hard-masked. I've reconsidered, though, and seeing the new
timeline upstream published for the 4.0.1, I agree. We'll see about
4.0.1's quality...
Thus, KDE 4.0.0 is going to go in hard-masked.
--
Best regards, Wulf
Chris Gianelloni
> Thanks Chris. I just went through the Gentoo Weekly News guide (which
> is a little outdated, but still quite helpful). Are there any other
> scripts other than glsa2gwn.py and bugs2gwn.py that need to be run?
Yeah, there's other scripts. If you check gentoo/src/gwn, you'll find
them all. Basically, you need get_glsas.py (which needs glsa2gwn.py)
which you run against the last GWN and it gives you all GLSA since. Of
course, you'll have to modify the first one manually, since it'll give
you everything since October 15th. Speaking of which, it might be a
good idea for us to put out at least one "stats-only" GWN with all of
the stats since October 15th until the newest edition (whenever that may
be). Taking Robin's output for the adds/removes, you feed the file to
gwn_adds_removes.py which does all the good stuff like formatting and
pulling dev names automatically. The gwn_bugzilla_report_en.py pulls
the bugzilla stats. If you run it on its own, it'll give you the stats
for the last week, starting from the previous day. It also accepts a
date range so you can specify the dates. If we switch to a monthly
newsletter, it would probably be best to change it to simply pull all
the stats for a given month (like December).
Ryan's "last rites" stuff was always properly formatted, so a simple
paste is all you need there. It would be nice to get Robin's
adds/removes to be processed automatically through gwn_adds_removes.py
and sent to gwn-feedback already formatted.
That covers the stats. Aside from that, there is the gwn_to_text.sh and
gwn2txt.xsl, which does the XML -> text conversion for emailing.
Something that I always wanted was something in the XSL which would
allow us to mark a GWN as "published" and disallow further changes.
Basically, you would do something like put in a <published> tag (or
whatever) and a few things would happen:
#1 - That GWN would no longer be editable. This is actually a good
thing, as changes after publishing has been something that's bitten us a
few times, especially given the nature of the emailed editions of the
GWN. Rather than change the GWN after it is published, I planned on
doing a "Corrections" type section where we would list any mistakes
(worth mentioning, not typos and such) in the previous GWN.
#2 - That GWN gets automatically converted to plain text via a
post-commit hook and automatically emailed to the GWN list.
#3 - That GWN is published to the front page. How this would be done is
still something up in the air. Perhaps adding a <summary> tag which
would allow you to set the summary, which would show up on the front
page, in the GWN itself, even if it is never displayed directly in the
GWN edition.
The idea is to take all of the steps which could be easily automated and
do so, saving the GWN editor a lot of time doing manual/menial copy and
pasting.
> I'll try and co-ordinate with infra to get them running automatically
> on a monthly basis. Is there anything else I need to know?
>
> A few points:
>
> 1) I'm going to create a sub-project called 'GMN' under the PR
> project, which will supersede the GWN project.
That sounds like a good idea.
> 2) I'm planning to get the first issue out by 21st of this month, and
> subsequently on the third monday of every month.
Are you planning on having the 21st edition show stats for December,
or... ?
> 3) Can we have email aliases g...@gentoo.org and gmn-...@gentoo.org
> for purposes of this project? (It sounds silly to ask for feedback on
> the GMN at gwn-fe...@gentoo.org)
Sounds good to me. What is the purpose of 2 aliases, though? We found
that people had enough problems with only one email to send to, so I'm
just curious what your thinking is here.
> 4) Can we 'move' the gentoo-gwn mailing list to gentoo-gmn?
Definitely.
> @Christian, William and Ryan:
> Please do resume sending your articles as soon as I get the gmn email
> alias setup. I'll get in touch with you shortly after the necessary
> arrangements have been made.
Let me know once the alias is up and I'll forward along all of the stuff
people have submitted since October. Whether you use it all (or none of
it) at least you'll have it.
> Any suggestions/tips/comments on the new venture, are of course, more
> than welcome.
Feel free to ask me any questions that you have along the way. I tried
to make publishing the GWN easier, but I still didn't get nearly as much
accomplished as I had wished.
Fabian Groffen
http://article.gmane.org/gmane.linux.gentoo.alt/3329
In short: gcc inserts 64-bits library paths which causes the linker
first to look inside the host dirs, then in my prefix lib dirs, which
creates interesting problems, since the runtime linker gets our runpath
directions to look in the prefix lib dirs first. Anyway, it makes
linking/runtime fail in cases where the host provided libs are
incompatible with the prefix provided ones.
Added to that that when I implemented the ldwrapper on amd64 (fedora)
linux I didn't fully understand the full multilib picture, some
decisions I made there now just feel plain wrong, especially given that
each distro seems to implement the multilib thing different (Gentoo:
/lib = native bits size, Fedora: /lib = 32-bits, Debian ...).
I didn't get it fully right in my post above though, because every
distro/os has a kernel configured in such a way that for a 64-bits
object, the search path points to the 64-bits host-specific lib paths.
So it seems that only binutils doesn't want to know about 64-bits
host-specific lib paths, and gcc takes actions to compensate that.
Thanks.
--
Fabian Groffen
Gentoo on a different level
--
gento...@lists.gentoo.org mailing list
Mike Frysinger
> On 11-01-2008 21:52:08 -0500, Mike Frysinger wrote:
> > On Tuesday 08 January 2008, Fabian Groffen wrote:
> > > - sort out the 64-bits targets with their multilib-hell forced upon us
> >
> > dont know exactly what you're referring to, but multilib is completely
> > optional.
>
> http://article.gmane.org/gmane.linux.gentoo.alt/3329
sorry, when i first read the multilib-hell, i assumed you meant the Gentoo
pieces rather than the binutils/gcc pieces.
i could post some corrections to the piece there, but in the end, they wouldnt
get you to a final working solution.
> Added to that that when I implemented the ldwrapper on amd64 (fedora)
> linux I didn't fully understand the full multilib picture, some
> decisions I made there now just feel plain wrong, especially given that
> each distro seems to implement the multilib thing different (Gentoo:
> /lib = native bits size, Fedora: /lib = 32-bits, Debian ...).
> I didn't get it fully right in my post above though, because every
> distro/os has a kernel configured in such a way that for a 64-bits
> object, the search path points to the 64-bits host-specific lib paths.
> So it seems that only binutils doesn't want to know about 64-bits
> host-specific lib paths, and gcc takes actions to compensate that.
i dont know why you keep saying "kernel" over and over when the kernel plays
no role here whatsoever. if you want to keep things sane, i would say just
follow the tool convention and any/all distro conventions be damned.
longer term, i'm really not familiar with how the prefix stuff is architected,
so i cant give much guidance unless i sat down and learned it.
-mike
Hans de Graaff
> XEmacs:
> I cannot tell much, but graaff seems to have closed most of the severe
> bugs and worked on having more/bette eclasses for the app-xemacs
> category.
Most bugs are closed and the ones remaining have mostly been discussed
with upstream, although that doesn't mean a solution is forthcoming in
all cases. We are also fully in sync with upstream's stable elisp
packages.
Next steps:
- replace the xemacs-packages-sumo package with a meta package so that
we can avoid file collisions all over the place
- check packages with an emacs use flag to see if xemacs can also be
supported
- include xemacs 21.5 in the tree after the next upstream release; with
this release the package files will also move from /usr/lib
to /usr/share
Hans
Hans de Graaff
> Are we fine?
Speaking for the ruby herd (which isn't a project and doesn't have a
lead, but I'm sure Richard or Josh will correct any mistakes I make):
No. Even though there are plenty of people in the herd only a few of us
commit on a regular basis. We could use more people helping out with
ruby stuff, especially now that ruby 1.9 has been released. At the
moment our bug list is only growing, and we don't have much time to
pro-actively bump any of the packages.
On the bright side we've identified and partly fixed a number of eclass
issues, and things are shaping up in that department.
Future plans:
- get ruby 1.9 into the tree and allow for it work in parallel with ruby
1.8.
- rework the gems eclass so that we can actually test and patch gems
without grossly abusing ebuild conventions.
- create a ruby project to make coordination a bit easier and have a
specific place for in-progress stuff and general knowledge on ruby in
Gentoo.
- recruit some more people to help out with ruby.
Kind regards,
Hans
Luis Francisco Araujo
Hash: SHA1
Hello,
A brief summary about the Gentoo GUIs project:
1 - Markus (jokey) recently released a new version of Maintainer-Helper.
It already has the basic operations running and some people are working
in a Gtk+ port.
http://dev.gentoo.org/~jokey/maintainer-helper
2 - Donnie (dberkholz) is currently working on a pkgcore back-end for
packagekit. This will allow to easily connect graphical interfaces to
this package manager. Contact him for further information.
http://www.pkgcore.org
http://www.packagekit.org
3 - Me (araujo) released a new version of Himerge. It has some bug fixes
and a few new operations added. Check the Changelog or web-site.
http://www.haskell.org/himerge
We also expect to upload a few screen-shots of these projects somewhere
in the coming days; for further details about any progress, please check
#gentoo-guis or the gentoo-guis mailing list.
Thanks
- --
Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHjPUcBCmRZan6aegRAt1UAKDcmGHQY2FSEp1w9dqpkXgOHoKtGACgoAA+
rQVum/VrWiz7dQ1QXZeAUkE=
=SKGW
-----END PGP SIGNATURE-----
--
gento...@lists.gentoo.org mailing list
Marijn Schouten (hkBst)
Hash: SHA1
Luca Barbato wrote:
| Here is a list of interesting questions: "Are we fine?" "What are we
| going to do?"
|
| Please project leaders try to reply in short.
To complete the reports for the Lisp project, I will now report for the Common Lisp and
Scheme stuff.
How are we doing?
We are seriously understaffed. Joslwah and me are the only devs working here. To make it
easier for users to help and get experience we have a git overlay.
My own focus is the Scheme area, Joslwah does CL, but he is very busy with real life and
work so I'm trying to help out there too. This means that I try to keep at least CL
implementations current in the main tree. Almost all other CL ebuilds are unmaintained in
main tree. We have one very active user (Stelian Ionescu) maintaining a lot of this other
CL stuff in our overlay who will hopefully be recruited.
For Scheme most of the ebuilds we have are implementations. Anything that doesn't support
the amd64 architecture is not maintained in main tree by me. This means that R6RS
implementations Larceny and Ikarus for example are in our overlay, but I'm not sure how
well they work. There is little time to add non-implementations, but we have bugs for most
of the stuff I want added. Some users have helped in the past and one is helping currently
whom I hope to recruit.
| What are we going to do:
Keep implementations current and add new implementations to complete my collection.
Hopefully do some recruiting. Maybe complete a wrapper script so it is possible to
superficially test the more than a dozen Scheme implementations we have. Try to interest
more people in Lisp. On that note:
Lisp is a family of very flexible and powerful programming languages. Compared to other
languages there are fewer restrictions (if any), more supported paradigms, more powerful
primitives (first-class continuations in Scheme for example) and infinitely better
metaprogramming facilities due to superior lack of syntax.
Interested parentheses-non-bigots are very welcome to join us in our IRC channel.
Marijn
"Any sufficiently complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of Common Lisp."
— Philip Greenspun, often called Greenspun's Tenth Rule of Programming
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHjgKpp/VmCx0OL2wRAo6wAJ9ff056rDMZ/rCD21lDpyzJIUp1nwCghODl
8I7fNkL7jE6h7FjiaPibwBI=
=G3qR