Re: [gentoo-dev] Gentoo Foundation Elections - Last Call for voting
Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] said: Hi. As we've stated before and is listed on the election page[1], the voting period lasts from 00:00.00 UTC February 14th (Thursday) to 23:59.59 UTC February 28th (Thursday). Thus, there's little less than 48 hours to cast your vote. At the moment 24% of the eligible voters have submitted their ballots[1]. Vote now if you want to have an influence in the election. it's not just that. after the trouble of the last months, it would be great if the next trustees could feel confident about their mandate. it would also be a clear signal to our users, that we (the devs and former devs) feel these issues are important as well. if you dont care about the foundation, you can still vote 'dont care', by putting all candidates on the same line. by not voting at all you boycot the democratic nature of the foundation. it would be intersting to hear from all those who choose not to vote, why they did so - in order to address whatever concerns they may have in the future. likewise it may be interesting to hear from those who already voted. now, everybody vote! ;) here are the step-by-step instructions on how to vote (from the website): Eligible current Gentoo devs should login to dev.gentoo.org and run the following commands, in the order specified. - votify --new trustees2008 - This creates a new ballot in your homedir. - Edit the .ballot-trustees2008 file and rank the candidates. - Once you're sure, run votify --verify trustees2008 to check the validity of the ballot. - If that goes through fine, the next and final step is to submit your vote using votify --submit trustees2008 - In case you're stuck, detailed help can be accessed by using votify --help or feel free to drop by #gentoo-elections on IRC. If you think you are eligible to vote, but cannot, please contact one of the officials. - Grab a beer, have fun, sit back and enjoy the show..till we announce the results ;) The remaining Foundation members (ex-devs), should email their ballot to the 3 election officials, signing the mail with their gpg key. * [1] - http://www.gentoo.org/proj/en/elections/foundation-200802.xml For the election officials, -- Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / SPARC / KDE signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Google SOC 2008
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] Last rites: mail-filter/dovecot-dspam
+# Benedikt Böhm [EMAIL PROTECTED] (27 Feb 2008) +# Masked for removal +# obsoleted by mail-filter/dovecot-antispam +mail-filter/dovecot-dspam -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
On Wed, 27 Feb 2008 09:42:05 +0100, Fabian Groffen [EMAIL PROTECTED]
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
[gentoo-dev] Re: Google SOC 2008
joshua jackson [EMAIL PROTECTED] posted [EMAIL PROTECTED], 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
Fabian Groffen [EMAIL PROTECTED] 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
On 27-02-2008 10:46:43 +, Roy Marples wrote:
On Wed, 27 Feb 2008 09:42:05 +0100, Fabian Groffen [EMAIL PROTECTED]
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
On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen [EMAIL PROTECTED]
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
On 27-02-2008 13:56:51 +, Roy Marples wrote:
On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen [EMAIL PROTECTED]
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!
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] Re: What is bump request?
On Tue, 2008-02-26 at 20:47 -0600, Ryan Hill wrote: Shaochun Wang wrote: I see the phrase bump request in bugzilla of Gentoo. What does it mean? A request to update the version of a package in portage to a later one, usually the latest released. It is also done by many people as an attempt to get the developer to look at an issue. This is usually done by people used to web forums, where things are sorted by the most recent and things disappear off the front page over time. Most of these people either do not realize that bugs do not act the same as a web forum, or they're simply rude and trying to tell the developer that they think that their issue is more important than others. ;] Generally, bump request means to bump the version of a package, whereas just bump is for bumping the thread... -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] MESA i965 SUPPORT PLEASE!
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!
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
On Wednesday 27 February 2008 14:21:58 Fabian Groffen wrote:
On 27-02-2008 13:56:51 +, Roy Marples wrote:
On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen [EMAIL PROTECTED]
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
[gentoo-dev] The app-misc/beagle in portage is seriously outdated!
Hi all: The app-misc/beagle is portage is seriously outdated! I remember that the developer of this beagle ebuild posted a mail saying that he/she had no time to maintain this package and looked for new maintainer. After such a long time, nothing happened to the beagle ebuild. How to change this situation? Is the original maintainer is still active now? BTW, besides the beagle bump request in the bugzilla of Gentoo, is there any way to let us normal users get beagle up to date? -- Shaochun Wang [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
