[gentoo-dev] Google SOC 2008

[gentoo-dev] Google SOC 2008

[joshua jackson]

All,

Google is once again doing the summer of code for students. I'm helping
organize it this year and am putting out a call for some elements to help.

1) We need idea's for things to do. Diego has already submitted some via
his blog which have been taken into consideration.
2) We need mentors, so far confirmed I have: Diego and Saleem

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Rémi Cardona]

joshua jackson a écrit :
> 2) We need mentors, so far confirmed I have: Diego and Saleem

What kind of work is involved there? I wouldn't mind being a mentor but 
I'd like to know a bit more about what's expected from a "good" mentor.

Thanks,

Rémi
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[joshua jackson]

Rémi Cardona wrote:
> joshua jackson a écrit :
>> 2) We need mentors, so far confirmed I have: Diego and Saleem
>
> What kind of work is involved there? I wouldn't mind being a mentor
> but I'd like to know a bit more about what's expected from a "good"
> mentor.
>
> Thanks,
>
> Rémi
There's a few requirements. Being decent in a language or multiple
languages would certainly be a plus, as the students are writing code.
having someone writing something in C or C++ when you've never touched
it wouldn't exactly work out that well obviously.

Having time to interact with the student as well. They are getting paid
as are we as an organization, so helping them and giving them idea's is
needed. Touching base and making sure they are still progressing on
their projects. Its summer...but they are being paid to work so it is a
job as I hope as a mentor you would take a similar approach as well.

Basically you act as a technical boss/mentor/leader to someone.

One area I'm working on for this year is goals within the overall goal
that can be implemented hopefully even if the project isn't fully
finished before the end of the project.

For the mentor it won't be a full time commitment but having time to
talk with/help someone with their project and explain how to implement
this feature or get this information from Gentoo's system would take
some time.

As a warning some people come on board with excellent programming
ability that you don't need to do much with/for. Some well its their
first real jump into programming and need more attention. I plan on
having a few additional questions for the Gentoo related applications to
help define that kind of thing and hope to get people together in such a
way.

As well a few of the people who are helping run it have agreed to help
poke/get updates from the mentors and step in and help in whatever way
possible to the students as well. Basically, we want as many projects to
succeed as possible and become a daily tool or vastly improved tools as
possible. Its certainly something that is possible.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Alec Warner]

On 2/26/08, joshua jackson <tsunam@gentoo.org> wrote:
> Rémi Cardona wrote:
>  > joshua jackson a écrit :
>  >> 2) We need mentors, so far confirmed I have: Diego and Saleem
>  >
>  > What kind of work is involved there? I wouldn't mind being a mentor
>  > but I'd like to know a bit more about what's expected from a "good"
>  > mentor.

I hope to have documentation up by the end of the week.

>  >
>  > Thanks,
>  >
>  > Rémi
>
> There's a few requirements. Being decent in a language or multiple
>  languages would certainly be a plus, as the students are writing code.
>  having someone writing something in C or C++ when you've never touched
>  it wouldn't exactly work out that well obviously.

You will reviewing the student's ideas and work.  You will need
whatever skills are required to to that; it will depend highy on what
project you choose to mentor.

>
>  Having time to interact with the student as well. They are getting paid
>  as are we as an organization, so helping them and giving them idea's is
>  needed. Touching base and making sure they are still progressing on
>  their projects. Its summer...but they are being paid to work so it is a
>  job as I hope as a mentor you would take a similar approach as well.

You should expect to spend a minimum of five (5) hours a week doing
reviews of your student's code.  Ideally you would make remarks for
readability and documentation as well as design and implementation.
You should meet with your student regularly to discuss progress; if
the student is having problems they should be brought up and dealt
with.  You should run your students code to make sure it functions as
he or she said it would.  If it has tests, run those too.  If it
doesn't have tests; ask the student to write some ;)

>
>  Basically you act as a technical boss/mentor/leader to someone.

I would argue that you are a peer, not a boss.  In the end, someone
the student should probably take advice from in order to have a
decently working product by summer's end.

>
>  One area I'm working on for this year is goals within the overall goal
>  that can be implemented hopefully even if the project isn't fully
>  finished before the end of the project.
>
>  For the mentor it won't be a full time commitment but having time to
>  talk with/help someone with their project and explain how to implement
>  this feature or get this information from Gentoo's system would take
>  some time.
>
>  As a warning some people come on board with excellent programming
>  ability that you don't need to do much with/for. Some well its their
>  first real jump into programming and need more attention. I plan on
>  having a few additional questions for the Gentoo related applications to
>  help define that kind of thing and hope to get people together in such a
>  way.

While true I don't think it is fair for the 'superstar' guy to just
let him do whatever.
*review their code*.  Read it, run it, see what it does.  If the
student says they wrote it in 3 hours and it is awesome and well
commented try running it through a profiler; find places where it
could be improved.  Look for poorly implemented algorithms, memory
leaks, over-use of memory etc...

>
>  As well a few of the people who are helping run it have agreed to help
>  poke/get updates from the mentors and step in and help in whatever way
>  possible to the students as well. Basically, we want as many projects to
>  succeed as possible and become a daily tool or vastly improved tools as
>  possible. Its certainly something that is possible.

My ideas are all insane (I probably only did half when I was a mentor)
but I want the students to have a good experience and I want the code
to not suck and that requires a mentor who actually gives a damn and
is willing to put time into it.

-Alec

>
>
>  --
>  gentoo-dev@lists.gentoo.org mailing list
>
>
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Fabian Groffen]

On 26-02-2008 10:32:45 -0800, joshua jackson wrote:
> All,
> 
> Google is once again doing the summer of code for students. I'm helping
> organize it this year and am putting out a call for some elements to help.
> 
> 1) We need idea's for things to do. Diego has already submitted some via
> his blog which have been taken into consideration.

- sandbox porting to Darwin, Solaris, FreeBSD (flameeyes), NetBSD and
  OpenBSD (would love AIX, IRIX, True64, HPUX and Interix too ;) )
- sandbox implementation of bug #205312
- baselayout porting to Prefix (mostly the start stop mechanisms)
- scanmacho (scanelf for Darwin) tool (to replace otool)
- make packages.g.o searchable
- combine packages.g.o and tinderbox.d.g.o
- binary Prefix bootstrap (ultimately using what's on tinderbox.d.g.o)

> 2) We need mentors, so far confirmed I have: Diego and Saleem

For the above things where I don't step on others' toes, yes.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Google SOC 2008

[Duncan]

joshua jackson <tsunam@gentoo.org> posted 47C4A08C.3040708@gentoo.org,
excerpted below, on  Tue, 26 Feb 2008 15:28:12 -0800:

> Rémi Cardona wrote:
>> joshua jackson a écrit :
>>> 2) We need mentors, so far confirmed I have: Diego and Saleem
>>
>> What kind of work is involved there? I wouldn't mind being a mentor but
>> I'd like to know a bit more about what's expected from a "good" mentor.

> There's a few requirements. Being decent in a language or multiple
> languages would certainly be a plus, as the students are writing code.
> having someone writing something in C or C++ when you've never touched
> it wouldn't exactly work out that well obviously.
> 
> Having time to interact with the student as well. [snip]

I saw some discussion earlier about the possibility/goal of having backup 
mentors as well.  Someone that would keep familiar enough with what's 
going on to step in if the primary mentor has "things" happen and isn't 
as available as they intended to be, but (unless the two team as true co-
mentors) wouldn't need to do the detail code reviewing, performance 
auditing, or whatever, unless those "things" /did/ happen to the primary 
mentor.

IOW, someone to keep the whole project afloat if something does happen to 
the primary mentor/gentoo-contact-point.  If I'm not mistaken, the 
original comment I read suggesting this pointed out that there had been a 
need for a backup mentor for at least one project, that had ended up not 
going much of anywhere because there wasn't one.  Such a run of events 
would certainly be a shame, both for Gentoo and for the student in 
question, so if it can be avoided...

Of course, with only two mentors (now possibly three) volunteered so far, 
that's not so practical, but perhaps there are some who would prefer to 
avoid primary mentorship if possible, but wouldn't mind doing it if it 
becomes necessary to avoid /dev/null-ing the project.

It's also possible some would be available as co-mentors.

So anyone qualified and interested, I'm sure it'll help both Gentoo and 
the student you backup- or co-mentor. =8^)

-- 
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

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Roy Marples]

On Wed, 27 Feb 2008 09:42:05 +0100, Fabian Groffen <grobian@gentoo.org>
wrote:
> - baselayout porting to Prefix (mostly the start stop mechanisms)

What start stop mechanics do you mean?

OpenRC already has full FreeBSD jail support in services like do
depend() { keyword nojail; }

That effectively disables the automatic running of services by rc itself,
such as fsck, mounting and stuff as that's taken care of by the host OS.
Running in Prefix is pretty much the same as a jail from OpenRC's
perspective
(correct me if I'm wrong) so all we would have to do is tell OpenRC that
it's
currently in a jail. Presently this is done only for FreeBSD by testing
sysctl values. Maybe we could turn this into a compile option for Prefix.

Also, we now support services in directories other than /etc/init.d,
although
this is currently hard coded to /usr/local/etc/init.d.

Thanks

Roy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Damian Florczyk]

Fabian Groffen <grobian@gentoo.org> wrote:

> On 26-02-2008 10:32:45 -0800, joshua jackson wrote:
> > All,
> > 
> > Google is once again doing the summer of code for students. I'm helping
> > organize it this year and am putting out a call for some elements to help.
> > 
> > 1) We need idea's for things to do. Diego has already submitted some via
> > his blog which have been taken into consideration.
> 
> - sandbox porting to Darwin, Solaris, FreeBSD (flameeyes), NetBSD and
>   OpenBSD (would love AIX, IRIX, True64, HPUX and Interix too ;) )
> - sandbox implementation of bug #205312
> - baselayout porting to Prefix (mostly the start stop mechanisms)
> - scanmacho (scanelf for Darwin) tool (to replace otool)
> - make packages.g.o searchable
> - combine packages.g.o and tinderbox.d.g.o
> - binary Prefix bootstrap (ultimately using what's on tinderbox.d.g.o)
> 
> > 2) We need mentors, so far confirmed I have: Diego and Saleem
> 
> For the above things where I don't step on others' toes, yes.
> 
> 
Probaby i could do some mentor work afterall :-)

-- 
Damian Florczyk aka thunder
Gentoo Developer, Gentoo/NetBSD Development Lead
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Fabian Groffen]

On 27-02-2008 10:46:43 +0000, Roy Marples wrote:
> 
> On Wed, 27 Feb 2008 09:42:05 +0100, Fabian Groffen <grobian@gentoo.org>
> wrote:
> > - baselayout porting to Prefix (mostly the start stop mechanisms)
> 
> What start stop mechanics do you mean?
> 
> OpenRC already has full FreeBSD jail support in services like do
> depend() { keyword nojail; }
> 
> That effectively disables the automatic running of services by rc itself,
> such as fsck, mounting and stuff as that's taken care of by the host OS.
> Running in Prefix is pretty much the same as a jail from OpenRC's
> perspective
> (correct me if I'm wrong) so all we would have to do is tell OpenRC that
> it's
> currently in a jail. Presently this is done only for FreeBSD by testing
> sysctl values. Maybe we could turn this into a compile option for Prefix.
> 
> Also, we now support services in directories other than /etc/init.d,
> although
> this is currently hard coded to /usr/local/etc/init.d.

Well... that's great!  But a jail or a (ch)root is in general not the
same as a "prefix".  I have to look more closely at what openrc does
these days, but for the (ancient) version of baselayout we have in
prefix now, I recall that:
a) most of it didn't compile on Darwin and Solaris
b) hence we only use basically the functions.sh script (hacked up)
so what we need to have working is:
${EPREFIX}/etc/init.d/postgresql start
and similar.

And maybe even a sort of init-level stuff, such that one can start all
services in the Prefix and stop them as well.  That basically gets quite
useful once Prefix goes "privileged" and you could start sshd, slapd,
apache2, etc, etc. on privileged ports, and you really would like those
to be started as well in some correct order (on e.g. Solaris).


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Roy Marples]

On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen <grobian@gentoo.org>
wrote:
> Well... that's great!  But a jail or a (ch)root is in general not the
> same as a "prefix".

No, but it's the same kettle of fish as chroots, jails and vps systems -
basically
there is a need to disable dependencies that provide what the host already
does.
We current have nojail for FreeBSD jails, novps for VServer/OpenVZ systems
and
a few others. I would be trivial to add another no for prefix :)

>  I have to look more closely at what openrc does
> these days, but for the (ancient) version of baselayout we have in
> prefix now, I recall that:
> a) most of it didn't compile on Darwin and Solaris

It compiles and works on Linux/glibc/uclibc, FreeBSD-6 and NetBSD-4.
So it stands a fair chance of working on Darwin for sure.
I have no idea about Solaris, but it should work as it sports libkvm which
we
use to find processes.

> b) hence we only use basically the functions.sh script (hacked up)
> so what we need to have working is:
> ${EPREFIX}/etc/init.d/postgresql start
> and similar.
> 
> And maybe even a sort of init-level stuff, such that one can start all
> services in the Prefix and stop them as well.  That basically gets quite
> useful once Prefix goes "privileged" and you could start sshd, slapd,
> apache2, etc, etc. on privileged ports, and you really would like those
> to be started as well in some correct order (on e.g. Solaris).

If OpenRC compiles and /bin/sh points to a POSIX shell it should work as it
stands.
At present there is no need for the default interpreter to be changed, but
there may
be the need for Prefix.

Thanks

Roy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Fabian Groffen]

On 27-02-2008 13:56:51 +0000, Roy Marples wrote:
> 
> On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen <grobian@gentoo.org>
> wrote:
> > Well... that's great!  But a jail or a (ch)root is in general not the
> > same as a "prefix".
> 
> No, but it's the same kettle of fish as chroots, jails and vps systems -
> basically
> there is a need to disable dependencies that provide what the host already
> does.

Ok, the host will for instance do "net", so "need net" should indeed not
fail.  However I could imagine that "need net" would just get satisfied
or something, like by a dummy.

> We current have nojail for FreeBSD jails, novps for VServer/OpenVZ systems
> and
> a few others. I would be trivial to add another no for prefix :)

I just need the machinery of "runscript" as first thing, I suppose.  If
we need a dozen of no* things for that, it probably indicates some
problem, but could work for me.  I want a framework to start and stop
daemons in Prefix, and it feels obvious that we can reuse existing code
for that.

> >  I have to look more closely at what openrc does
> > these days, but for the (ancient) version of baselayout we have in
> > prefix now, I recall that:
> > a) most of it didn't compile on Darwin and Solaris
> 
> It compiles and works on Linux/glibc/uclibc, FreeBSD-6 and NetBSD-4.
> So it stands a fair chance of working on Darwin for sure.

Well...  I've some experience here, and I'm not as sure as you ;)
Anyway, I concur the codebase has changed dramatically since, and
probably in favour of portability.

> I have no idea about Solaris, but it should work as it sports libkvm which
> we use to find processes.

Part of the summer of code project to me would be to 1) evaluate to what
extent this is all necessary in the Prefix equivalent and 2) create/fix
the code.

> > And maybe even a sort of init-level stuff, such that one can start all
> > services in the Prefix and stop them as well.  That basically gets quite
> > useful once Prefix goes "privileged" and you could start sshd, slapd,
> > apache2, etc, etc. on privileged ports, and you really would like those
> > to be started as well in some correct order (on e.g. Solaris).
> 
> If OpenRC compiles and /bin/sh points to a POSIX shell it should work as it
> stands.

Ok, then we already fail here.
/bin/sh is no way POSIX, it is just bourne, so that's where we come in
and simply use /usr/bin/env {sh,bash,posix-sh} or a full path to make
your assumption true.

> At present there is no need for the default interpreter to be changed, but
> there may
> be the need for Prefix.

See above.  But that's trivial work, that we do all the time.  For the
GSoC I see more challenges in the rest of the job and to make some
obvious examples.

But then again, it was just a mere suggestion.  If everything is already
there then fine, but we still need someone (Google code or not) to do
it, as it's currently not.  I'm not sure how far OpenRC actually can
deal with unprivileged installs, so that are just things we have to find
out along the way.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] MESA i965 SUPPORT PLEASE!

[Mateusz Mierzwinski]

Another day with non compatible DRI on X. After 3 days of discover I've 
saw that Xorg must be compiled with same NPTL flag setting as MESA but 
guess what? Someone don't insert i965 card from VIDEO_CARD variable but 
Mesa sources allready provide that card's drivers. If I want to install 
Mesa with i965 card support I must download source from 
www.intellinuxgraphics.com by git and compile it by myself. But what 
should I do if I cannot enable NPTL flag in make compiled source without 
./configure script?. Better to add i965 to mesa VIDEO_CARD variable. I 
don't want to change compile profile to non-NPTL.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] MESA i965 SUPPORT PLEASE!

[Chris Gianelloni]

On Wed, 2008-02-27 at 20:11 +0100, Mateusz Mierzwinski wrote:
> Another day with non compatible DRI on X. After 3 days of discover I've 
> saw that Xorg must be compiled with same NPTL flag setting as MESA but 
> guess what? Someone don't insert i965 card from VIDEO_CARD variable but 
> Mesa sources allready provide that card's drivers. If I want to install 
> Mesa with i965 card support I must download source from 
> www.intellinuxgraphics.com by git and compile it by myself. But what 
> should I do if I cannot enable NPTL flag in make compiled source without 
> ./configure script?. Better to add i965 to mesa VIDEO_CARD variable. I 
> don't want to change compile profile to non-NPTL.

This belongs in a bug report.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] MESA i965 SUPPORT PLEASE!

[Chris Gianelloni]

On Wed, 2008-02-27 at 20:11 +0100, Mateusz Mierzwinski wrote:
> Another day with non compatible DRI on X. After 3 days of discover I've 
> saw that Xorg must be compiled with same NPTL flag setting as MESA but 
> guess what? Someone don't insert i965 card from VIDEO_CARD variable but 
> Mesa sources allready provide that card's drivers. If I want to install 
> Mesa with i965 card support I must download source from 
> www.intellinuxgraphics.com by git and compile it by myself. But what 
> should I do if I cannot enable NPTL flag in make compiled source without 
> ./configure script?. Better to add i965 to mesa VIDEO_CARD variable. I 
> don't want to change compile profile to non-NPTL.

Even better... i965 support is added by VIDEO_CARDS=i810 already.  You
don't need to do anything by hand...

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Roy Marples]

On Wednesday 27 February 2008 14:21:58 Fabian Groffen wrote:
> On 27-02-2008 13:56:51 +0000, Roy Marples wrote:
> > On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen <grobian@gentoo.org>
> >
> > wrote:
> > > Well... that's great!  But a jail or a (ch)root is in general not the
> > > same as a "prefix".
> >
> > No, but it's the same kettle of fish as chroots, jails and vps systems -
> > basically
> > there is a need to disable dependencies that provide what the host
> > already does.
>
> Ok, the host will for instance do "net", so "need net" should indeed not
> fail.  However I could imagine that "need net" would just get satisfied
> or something, like by a dummy.

Correct. lu_zero wanted OpenRC to work out of the box in a vanilla fbsd jail, 
hence the keyword instead of dummy scripts.

> > If OpenRC compiles and /bin/sh points to a POSIX shell it should work as
> > it stands.
>
> Ok, then we already fail here.
> /bin/sh is no way POSIX, it is just bourne, so that's where we come in
> and simply use /usr/bin/env {sh,bash,posix-sh} or a full path to make
> your assumption true.

make SH=/usr/local/bin/bash
now tweaks all the scripts accordingly.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] MESA i965 SUPPORT PLEASE!

[Mateusz Mierzwinski]

Chris Gianelloni pisze:
> On Wed, 2008-02-27 at 20:11 +0100, Mateusz Mierzwinski wrote:
>   
>> Another day with non compatible DRI on X. After 3 days of discover I've 
>> saw that Xorg must be compiled with same NPTL flag setting as MESA but 
>> guess what? Someone don't insert i965 card from VIDEO_CARD variable but 
>> Mesa sources allready provide that card's drivers. If I want to install 
>> Mesa with i965 card support I must download source from 
>> www.intellinuxgraphics.com by git and compile it by myself. But what 
>> should I do if I cannot enable NPTL flag in make compiled source without 
>> ./configure script?. Better to add i965 to mesa VIDEO_CARD variable. I 
>> don't want to change compile profile to non-NPTL.
>>     
>
> Even better... i965 support is added by VIDEO_CARDS=i810 already.  You
> don't need to do anything by hand...
>
>   
But I have question - Intel divides i810 driver and other intel drivers 
from mesa with own patch. If I enable i810 do I have HW support of Mesa 
(aka DRI/DRM) for i965 driver, or this will be done legacy by 
i810/i830/i915 driver? Intel X3100 works best on i965 DRI driver (aka 
/usr/lib64/dri/i965_dri.so).
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] MESA i965 SUPPORT PLEASE!

[Rémi Cardona]

Mateusz Mierzwinski a écrit :
> But I have question - Intel divides i810 driver and other intel drivers 
> from mesa with own patch. If I enable i810 do I have HW support of Mesa 
> (aka DRI/DRM) for i965 driver, or this will be done legacy by 
> i810/i830/i915 driver? Intel X3100 works best on i965 DRI driver (aka 
> /usr/lib64/dri/i965_dri.so).

1) Next time, please start a new thread. Hijacking threads like that is 
considered rude. So is your use of capital letters in your first message.

2) VIDEO_CARDS="i810" installs every piece of code that is related to 
Intel hardware, from i810 to i965. If a driver is missing, please report 
it to bugzilla.

3) I was planning on renaming all "i810" references to "intel" to 
simplify things, but it's more complicated than I thought, so I'll do 
that when xorg-server 1.5 is released.

Thanks

Rémi
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Roy Marples]

On Wed, 27 Feb 2008 15:21:58 +0100, Fabian Groffen <grobian@gentoo.org>
wrote:
> I'm not sure how far OpenRC actually can
> deal with unprivileged installs, so that are just things we have to find
> out along the way.

Provided you have permissions to start the configured programs, then it's
fine.
OpenRC now supports PREFIX=/home/roy/foo and PKG_PREFIX=/home/roy/bar.

PREFIX is where OpenRC installs to (also respects DESTDIR).
PKG_PREFIX is where packages install to if different.

So the only thing left (aside from bug fixing) is to instruct OpenRC
dependency
code that it's in a prefix and to respect the noprefix keyword in services,
or
to provide dummy services.

Thanks

Roy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Fabian Groffen]

On 28-02-2008 11:22:13 +0000, Roy Marples wrote:
> 
> On Wed, 27 Feb 2008 15:21:58 +0100, Fabian Groffen <grobian@gentoo.org>
> wrote:
> > I'm not sure how far OpenRC actually can
> > deal with unprivileged installs, so that are just things we have to find
> > out along the way.
> 
> Provided you have permissions to start the configured programs, then it's
> fine.
> OpenRC now supports PREFIX=/home/roy/foo and PKG_PREFIX=/home/roy/bar.
> 
> PREFIX is where OpenRC installs to (also respects DESTDIR).
> PKG_PREFIX is where packages install to if different.
> 
> So the only thing left (aside from bug fixing) is to instruct OpenRC
> dependency
> code that it's in a prefix and to respect the noprefix keyword in services,
> or
> to provide dummy services.

Right.  Assuming this will be enough to start, that means one GSoC
project less ;)

Thanks for the work anyway!


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On Tue, 26 Feb 2008 10:32:45 -0800
joshua jackson <tsunam@gentoo.org> wrote:

> All,
> 
> Google is once again doing the summer of code for students. I'm
> helping organize it this year and am putting out a call for some
> elements to help.
> 
> 1) We need idea's for things to do. Diego has already submitted some
> via his blog which have been taken into consideration.
> 2) We need mentors, so far confirmed I have: Diego and Saleem

Something nice would be to reimplement revdep-rebuild as a package set
for portage-2.2 (the ground work for that is already done, but most of
the processing logic from revdep-rebuild is still missing).
Unlike most other portage-related ideas this one doesn't require a huge
understanding of portage internals, and I'd be willing to mentor
applicants for this.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Google SOC 2008

[JoseAlberto]

I have some ideas to improve GNAP (last year was a nice experience):

- live upgrade
- squashfs pkgs
- unionfs

i think this 3 task can fit in only one project.

- use new catalyst

This is the hardest one adn must be a different project.

regards

El mar, 26-02-2008 a las 10:32 -0800, joshua jackson escribió:
> All,
> 
> Google is once again doing the summer of code for students. I'm helping
> organize it this year and am putting out a call for some elements to help.
> 
> 1) We need idea's for things to do. Diego has already submitted some via
> his blog which have been taken into consideration.
> 2) We need mentors, so far confirmed I have: Diego and Saleem
> 

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Alec Warner]

Check your idea into cvs.. ;)

On 2/29/08, JoseAlberto <bass@gentoo.org> wrote:
> I have some ideas to improve GNAP (last year was a nice experience):
>
>  - live upgrade
>  - squashfs pkgs
>  - unionfs
>
>  i think this 3 task can fit in only one project.
>
>  - use new catalyst
>
>  This is the hardest one adn must be a different project.
>
>  regards
>
>  El mar, 26-02-2008 a las 10:32 -0800, joshua jackson escribió:
>
> > All,
>  >
>  > Google is once again doing the summer of code for students. I'm helping
>  > organize it this year and am putting out a call for some elements to help.
>  >
>  > 1) We need idea's for things to do. Diego has already submitted some via
>  > his blog which have been taken into consideration.
>  > 2) We need mentors, so far confirmed I have: Diego and Saleem
>  >
>
>  --
>  gentoo-dev@lists.gentoo.org mailing list
>
>
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Luca Barbato]

joshua jackson wrote:
> All,
> 
> Google is once again doing the summer of code for students. I'm helping
> organize it this year and am putting out a call for some elements to help.
> 
> 1) We need idea's for things to do. Diego has already submitted some via
> his blog which have been taken into consideration.

- crossbuild support for a gentoo compatible package manager (up to the 
student pick which)
- eselect pm and emerge wrapper for alternate package managers.

> 2) We need mentors, so far confirmed I have: Diego and Saleem

add me.

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Roy Marples]

On Thursday 28 February 2008 11:22:13 Roy Marples wrote:
> So the only thing left (aside from bug fixing) is to instruct OpenRC
> dependency
> code that it's in a prefix and to respect the noprefix keyword in services,
> or
> to provide dummy services.

This is now done.

I have OpenRC fully working in a prefixed non priviledged install on a NetBSD 
box.

The only question I have left is what mechanism resets service state, as the 
prefixed state dir needs will presist between reboots which isn't desirable.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Fabian Groffen]

On 03-03-2008 13:36:25 +0000, Roy Marples wrote:
> On Thursday 28 February 2008 11:22:13 Roy Marples wrote:
> > So the only thing left (aside from bug fixing) is to instruct OpenRC
> > dependency
> > code that it's in a prefix and to respect the noprefix keyword in services,
> > or
> > to provide dummy services.
> 
> This is now done.
> 
> I have OpenRC fully working in a prefixed non priviledged install on a NetBSD 
> box.

Can you define how this is working?  Do you just have NetBSD and install
OpenRC in /my/arbitrary/path, or do you have a full set of utilities
under /my/arbitrary/path with OpenRC as one of them?

> The only question I have left is what mechanism resets service state, as the 
> prefixed state dir needs will presist between reboots which isn't desirable.

startprefix could maybe start some sort of process that lives on,
activated like keychain does, such that multiple startprefix invocations
do not start the system all the time -- if that is desired at all.  In
a real scenario it may be just a hook from the host OS's start/stop
mechanism to tell OpenRC in what state it should run.

If a service such as PostgreSQL is killed (maybe a reboot?) does OpenRC
then know it is not running any more?  I guess it does, so that's good
enough, IMO.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Michael Haubenwallner]

On Mon, 2008-03-03 at 15:53 +0100, Fabian Groffen wrote:
> On 03-03-2008 13:36:25 +0000, Roy Marples wrote:
> > On Thursday 28 February 2008 11:22:13 Roy Marples wrote:
> > > So the only thing left (aside from bug fixing) is to instruct OpenRC
> > > dependency
> > > code that it's in a prefix and to respect the noprefix keyword in services,
> > > or
> > > to provide dummy services.
> > 
> > This is now done.
> > 
> > I have OpenRC fully working in a prefixed non priviledged install on a NetBSD 
> > box.
> 
> Can you define how this is working?  Do you just have NetBSD and install
> OpenRC in /my/arbitrary/path, or do you have a full set of utilities
> under /my/arbitrary/path with OpenRC as one of them?
> 
> > The only question I have left is what mechanism resets service state, as the 
> > prefixed state dir needs will presist between reboots which isn't desirable.
> 
> startprefix could maybe start some sort of process that lives on,
> activated like keychain does, such that multiple startprefix invocations
> do not start the system all the time -- if that is desired at all. In
> a real scenario it may be just a hook from the host OS's start/stop
> mechanism to tell OpenRC in what state it should run.

Must admit not having looked at OpenRC yet - maybe I understood sth.
wrong, but:

+1 for registering OpenRC into host OS's specific init.d mechanism.

Here I'm doing so with distccd on ia64-hpux, having some (host OS
specific) script in (not yet gentoo-) prefix, understanding additional
'--install [name]' - or have a separate command for that.
This needs to be run as root once to register into host OS's init.d
mechanism.

For hpux fex this just is adding some symlinks:
/sbin/init.d/name -> /my/prefix/sbin/init.d/distccd
/sbin/rc3.d/S990name -> /sbin/init.d/name   # to start in runlevel 3
/sbin/rc2.d/K100name -> /sbin/init.d/name   # to kill for runlevel 2

When doing so with OpenRC's main process, it could integrate smoothly
with normal system reboot and start prefixed init.d scripts.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Roy Marples]

On Mon, 3 Mar 2008 15:53:20 +0100, Fabian Groffen <grobian@gentoo.org>
wrote:
> On 03-03-2008 13:36:25 +0000, Roy Marples wrote:
>> On Thursday 28 February 2008 11:22:13 Roy Marples wrote:
>> > So the only thing left (aside from bug fixing) is to instruct OpenRC
>> > dependency
>> > code that it's in a prefix and to respect the noprefix keyword in
> services,
>> > or
>> > to provide dummy services.
>>
>> This is now done.
>>
>> I have OpenRC fully working in a prefixed non priviledged install on a
> NetBSD
>> box.
> 
> Can you define how this is working?  Do you just have NetBSD and install
> OpenRC in /my/arbitrary/path, or do you have a full set of utilities
> under /my/arbitrary/path with OpenRC as one of them?

I did this in OpenRC source
rm -rf /home/roy/pkg
make PREFIX=/home/roy/pkg PKG_PREFIX=/usr/pkg install
Create Gentoo style init script in /home/roy/pkg/etc/init.d for say boinc
export PATH=$PATH:/home/roy/pkg/bin:/home/roy/pkg/sbin
rc-update add boinc default
rc default

boinc started

> 
>> The only question I have left is what mechanism resets service state, as
> the
>> prefixed state dir needs will presist between reboots which isn't
> desirable.
> 
> startprefix could maybe start some sort of process that lives on,
> activated like keychain does, such that multiple startprefix invocations
> do not start the system all the time -- if that is desired at all.  In
> a real scenario it may be just a hook from the host OS's start/stop
> mechanism to tell OpenRC in what state it should run.
> 
> If a service such as PostgreSQL is killed (maybe a reboot?) does OpenRC
> then know it is not running any more?  I guess it does, so that's good
> enough, IMO.

This needs to be done on startup

rc sysinit
rc default

Which is pretty much what we do in Gentoo anyway. Just ensure that the
sysinit
runlevel only runs once, as it will remove all state when run again.

Thanks

Roy

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Google SOC 2008

[Roy Marples]

On Mon, 03 Mar 2008 16:50:49 +0100, Michael Haubenwallner
<haubi@gentoo.org> wrote:
> For hpux fex this just is adding some symlinks:
> /sbin/init.d/name -> /my/prefix/sbin/init.d/distccd
> /sbin/rc3.d/S990name -> /sbin/init.d/name   # to start in runlevel 3
> /sbin/rc2.d/K100name -> /sbin/init.d/name   # to kill for runlevel 2
> 
> When doing so with OpenRC's main process, it could integrate smoothly
> with normal system reboot and start prefixed init.d scripts.

Yes, that should work fine if it ends up calling
/sbin/init.d/name start
and
/sbin/init.d/name stop
to start and stop it.

You just have to somehow inject
rc sysinit
into the boot process to remove all state data.

But a better way would be like so

/my/prefix/sbin/rc-wrapper
#/bin/sh
case "$1" in
   start) /my/prefix/sbin/rc default;;
   stop)  /my/prefix/sbin/rc single;;
esac

As you then get OpenRC handling the dependency order if you have >1
service.

Thanks

Roy

-- 
gentoo-dev@lists.gentoo.org mailing list