[gentoo-dev] Re: Request for Willikins
Hello there, Since the number of users and developers on #gentoo-el is growing fast , we would like to have a Willikins if possible. Thank you -- 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.
[gentoo-dev] Re: Files owned by multiple slots
Gilles wrote: so this wrapper could be installed in a separate eselect sort of package ? How exactly can this be done? If a gem creates five executables, would this mean that this gem comes in six ebuilds? If those kind of wrappers are generic enough, it could even be a single eselect package and gems would enable (symlink to wrapper) themselves at postinst. I'm an eselect n00b but this all sound like something an eselect module could do. The wrappers can't be boiled down to one unified wrapper. Cheers, -sven
Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool
Michael, > Seems you didn't really understand my problem yet - another try: > The *one* and *same* user does need different settings at the *same* > time depending on the project he's currently working on in different > shells. The actual setting needs to be set up by the project's > environment script (when the users enters the project), not the user's > profile script (when the user logs in). > Ok, now I fully understand you and I agree. A new feature? Mmm... This can be managed by profile creation and switching. Imagine, user can create a profile with it's current uselect settings, select a default profile, select the active profile on-the-fly, and on and on... Works, but not automatic... Maybe we can optimize this by having a similar behavior of .svn folders on svn settings. How about having the profile switch automatic whenever you call "uselect something" getting the current profile settings from current dir's .uselect folder? I am starting the plans on profile managing today. This now gets interesting. Thanks! Cheers, Sérgio -- Sérgio Almeida mephx @ freenode
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] Google SoC @ Gentoo - Universal Select Tool
On Tue, 2009-05-12 at 15:32 +0100, Sérgio Almeida wrote: > > On Mon, 2009-05-04 at 22:01 +0100, Sérgio Almeida wrote: > > > Here are the main interest ideas: > > > * actions can be run system-wide and per-user: > > > # action user moo > > > # action system moo > > > > Are there any thoughts to support something more fine granular settings > > than system and user? > > Indeed, user is not "for all the users". It's an action that can be run > by the users to change it's own settings without touching the system's > fallback default. Seems you didn't really understand my problem yet - another try: The *one* and *same* user does need different settings at the *same* time depending on the project he's currently working on in different shells. The actual setting needs to be set up by the project's environment script (when the users enters the project), not the user's profile script (when the user logs in). > That's the point of the uselect tool. Per-System settings, Per-User > settings (2 different ssh sessions of the same user can still have > different environment settings too). This maybe is what I'm after: Question still is how to easily set up the different environment? > I work as a sysadmin and manage mainly multi-user gentoo environments > where people develop calculus c/python/fortran/R/whatever code using > wathever utilities we can imagine. Everytime a new project is beeing > done people need to set the environment variables themselves when they > are kind enough not to ask me. That's mainly the whole purpose of this > uselect tool, easy multi user environments managing. Seems like we have a similar job ;) Maybe it's the wording only, but in addition to the multi-user dimension I'm still missing the multi-project dimension for one user. /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool
Hello, On Tue, 2009-05-12 at 10:40 +0200, Michael Haubenwallner wrote:< > If there is a different place for requirement discussion of Gentoo > specific GSoC projects, please tell, and sorry for bothering here then. There is another mailing list, but i am sure it doesn't get to as much dev's as this one gets. > > On Mon, 2009-05-04 at 22:01 +0100, Sérgio Almeida wrote: > > Here are the main interest ideas: > > * actions can be run system-wide and per-user: > > # action user moo > > # action system moo > > Are there any thoughts to support something more fine granular settings > than system and user? > Indeed, user is not "for all the users". It's an action that can be run by the users to change it's own settings without touching the system's fallback default. > What I'm after: > We are developing multiple source projects with multiple release > branches on the same host here. These projects do have some script to > set up the project specific environment. One os-user is working on > multiple projects or branches, entering a project's environment by > sourcing its environment script. > > Naturally, these projects do have different requirements to - for > example - the java-vm version. The project admin needs to select the > java-vm on a per-project basis, and does want to use the system-vm as > fallback, never wants to use the user-vm. > > With current eselect (and java-config-2), this would be something like > setting $HOME on the per-project basis - or not using java-config at > all. > > Would it make sense to explicitly set the system-vm (whatever version it > is or will be changed to), while leaving it unset would fall back to the > user-vm? That's the point of the uselect tool. Per-System settings, Per-User settings (2 different ssh sessions of the same user can still have different environment settings too). I work as a sysadmin and manage mainly multi-user gentoo environments where people develop calculus c/python/fortran/R/whatever code using wathever utilities we can imagine. Everytime a new project is beeing done people need to set the environment variables themselves when they are kind enough not to ask me. That's mainly the whole purpose of this uselect tool, easy multi user environments managing. > > More toughts? > > Thanks! I Thank you! > > /haubi/ I would be glad if developers from the *-config utilities could post here and say what their utilities can do that eselect is/was incapable of doing and also the reason why their tools were created for us to find a way that a new "universal select tool" can gather all of *-config features with somthing like these proposed modules. Cheers, Sérgio -- Sérgio Almeida mephx @ freenode
Re: [gentoo-dev] Files owned by multiple slots
Le lundi 11 mai 2009 à 11:14 +0200, Sven Schwyn a écrit : > Hi > > This question popped up while discussing how to deal with Ruby gems > on > Gentoo in a way that gives the user the freedom to choose Portage, > RubyGems or both for gem management. [snip] > If a Ruby gem contains and installs executables, then those are mere > wrappers to a Ruby runner object. As per default, the wrapper will run > the most up-to-date code. You can, however, tell the wrapper to run a > specific code version (e.g. rake _0.7.3_ --version). so this wrapper could be installed in a separate eselect sort of package ? If those kind of wrappers are generic enough, it could even be a single eselect package and gems would enable (symlink to wrapper) themselves at postinst. I'm an eselect n00b but this all sound like something an eselect module could do. -- Gilles Dartiguelongue Gentoo
Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool
If there is a different place for requirement discussion of Gentoo specific GSoC projects, please tell, and sorry for bothering here then. On Mon, 2009-05-04 at 22:01 +0100, Sérgio Almeida wrote: > Here are the main interest ideas: > * actions can be run system-wide and per-user: > # action user moo > # action system moo Are there any thoughts to support something more fine granular settings than system and user? What I'm after: We are developing multiple source projects with multiple release branches on the same host here. These projects do have some script to set up the project specific environment. One os-user is working on multiple projects or branches, entering a project's environment by sourcing its environment script. Naturally, these projects do have different requirements to - for example - the java-vm version. The project admin needs to select the java-vm on a per-project basis, and does want to use the system-vm as fallback, never wants to use the user-vm. With current eselect (and java-config-2), this would be something like setting $HOME on the per-project basis - or not using java-config at all. Would it make sense to explicitly set the system-vm (whatever version it is or will be changed to), while leaving it unset would fall back to the user-vm? More toughts? Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] An Introduction to Gentoo Prefix
On 12-05-2009 08:28:15 +0200, Mounir Lamouri wrote: > Fabian Groffen wrote: > > Therefore, we plan to focus on merging back the many patches and > > extensions from our Prefix overlay into the Gentoo mainline tree. For > > us, this roadmap looks as follows: > > [snip] > I used Gentoo on MacOS X (which is part of Gentoo Prefix, isn't it ?) > and it was very promising. I'm glad this project is now in a mature shape :) If you mean "Gentoo for Mac OS X", then no. "Gentoo Prefix on Mac OS X" is a different approach than the former. And, Gentoo Prefix is not "all about Mac OS X". Just to make this clear. > About the merge, does this mean we will have to care bout other-OS > specific options ? For example, mac os options. Or it will be the work > of the Prefix team ? To take your example of Mac OS X specific options, they are IMO part of the job of the Prefix/OSX "arch team". However, yes, we would like to ask you to "care" about other OSes. We don't expect you to solve the issues, but a bug or IRC ping would be nice. -- Fabian Groffen Gentoo on a different level
