Re: Re: [gentoo-dev] GSoC
On 20:59 Wed 31 Mar , Serheo wrote: Google summer of code test message. Sorry for interuption. You might want to consider the impression you make on people when you send an email like this. When you're required to send an email, why not make it something useful and get people excited about your proposal? -- Sorry, You Right) I live in Russian Federation and I'm 5-th year student on speciality Software development. I.experienced in C++ ,C# and Rails development (I linked my CV with application on Gsoc site) and I'm really interested in participating this year in the GSoC. In the Ideas list I found an Gentoo Web Application and wrote an application (It's already on Gsoc site). All additional requrement requirement completed (mailing lists and patch). Thanks for your the and collaboration, I would happy to work on this project and appreciate any help I could get from mentors. Yours Faithfully.
[gentoo-dev] Is Gentoo dying?
Hell no, but ... We have lots of quite understaffed areas, to sum up in a positive way. Summing it up the negative way one might say, we have lots of areas were users might get the idea Gentoo already is dead. For example: - hardened-sources are nowadays only available in an experimental overlay, lots of users keep asking what's happening to the hardened-sources on both the -dev but also the -hardened mailinglist. Yeah, we do have people working on hardened stuff, but if people just take what's happening in the portage tree they might think that the hardened stuff they're relying on for their business isn't supported any longer. - Our formerly outstanding documentation still is somewhat maintained, but that's it. I haven't seen any new additions (both to our docs, but also to our docs-team) for years. People are constantly asking for a documentation wiki, but ... - Infra: One might get the idea our Infra team is just Robin (yeah, sure there are more people, but ) ... things are happening slowly (no offend - I fully understand that those few can't dedicate more of their spare time to infra work!), take overlays.g.o migration, Bugzie-3 migration and so on as an example. - Understaffed herds: For example net-mail, netmon and others - were missing lots of developers and their support in lots of areas. Sadly those areas are mostly those ones, one might need packages for their business servers from. - Website redesign - we had a contest some years ago, got a winner, someone started to adapt the design and somewhat that project fall asleep. - Speaking of our website, PR ... guess there's nothing more to add. So - what to do now? To be honest - I have no real clue. But a first step might be to collect your opinions on where we do lack manpower and ideas on how to solve this problems. A Wiki might be fitting well for that task *cough*. A next step might be to discuss every identified problem and discuss our options and ideas how to improve the situation. - Tobias -- Praxisbuch Nagios http://www.oreilly.de/catalog/pbnagiosger/ https://www.xing.com/profile/Tobias_Scherbaum signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Is Gentoo dying?
On 4/3/10 11:16 AM, Tobias Scherbaum wrote: Hell no, but ... We have lots of quite understaffed areas, to sum up in a positive way. Summing it up the negative way one might say, we have lots of areas were users might get the idea Gentoo already is dead. For example: - hardened-sources are nowadays only available in an experimental overlay, lots of users keep asking what's happening to the hardened-sources on both the -dev but also the -hardened mailinglist. I recently sent an e-mail to gentoo-dev, http://archives.gentoo.org/gentoo-dev/msg_2eb703ee97afc64a29e5d148457ac8d5.xml It seems that some work is being done, but there are people who volunteered to help, like me. What needs to be done with hardened-sources? Just a note: I'm using it on my servers, so I'm really interested in them being maintained, and I'm also able to test. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Is Gentoo dying?
On 04/03/2010 12:16 PM, Tobias Scherbaum wrote: - Infra: One might get the idea our Infra team is just Robin (yeah, sure there are more people, but ) ... things are happening slowly (no offend - I fully understand that those few can't dedicate more of their spare time to infra work!), take overlays.g.o migration, Bugzie-3 migration and so on as an example. My perception from the outside is also that it's sometimes hard to offer help. So if we now that we are busy then let's try to embrace others doing the work. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Is Gentoo dying?
On Sat, Apr 03, 2010 at 11:16:32AM +0200, Tobias Scherbaum wrote: Hell no, but ... Then avoid feeding the distrowatch trolls w/ sensational subjects please ;) We have lots of quite understaffed areas, to sum up in a positive way. Summing it up the negative way one might say, we have lots of areas were users might get the idea Gentoo already is dead. Got any metrics offhand? The reason I ask is that I can't think of a time when 'understaffed' wasn't an applicable term. Sidenote, if we *aren't* tracking the basics, it might be worthwhile. Shouldn't be too hard to grab the history of herds.xml for example and extract the relevant data. One thing to note... crappy support for something can draw people out to contribute. Hence asking about metrics- I wouldn't be surprised if the headcount for misc. projects is a cyclic rise/fall. At the very least I'd be curious about the pre and post git metrics, once that conversion is finished up. - Infra: One might get the idea our Infra team is just Robin (yeah, sure there are more people, but ) ... things are happening slowly (no offend - I fully understand that those few can't dedicate more of their spare time to infra work!), take overlays.g.o migration, Bugzie-3 migration and so on as an example. Relaying from IRC, overlays.g.o migration bits seem to be done... - Website redesign - we had a contest some years ago, got a winner, someone started to adapt the design and somewhat that project fall asleep. A status update on this one would be useful, even if it's just got no time, here's what is remaining so someone could jump in and help where possible. Personally I'd suggest trying to extract status updates from folk- it's more useful anyways to know what's needed to get various projects done. ~harring pgp3WZkFI335U.pgp Description: PGP signature
Re: [gentoo-dev] Is Gentoo dying?
On Sat, Apr 03, 2010 at 11:16:32AM +0200, Tobias Scherbaum wrote: - Infra: One might get the idea our Infra team is just Robin (yeah, sure there are more people, but ) ... things are happening slowly (no offend - I fully understand that those few can't dedicate more of their spare time to infra work!), take overlays.g.o migration, Bugzie-3 migration and so on as an example. - Presently in the infra team and active on a day-to-day basis: darkside ford_prefect halcy0n idl0r robbat2 - In the infra team and active several times/month: fox2mike kingtaco ramereth solar armin76 Problems in infra: - lack of communication and perceived transparency - We'd like to open read-only access to our Nagios soon... - lack of perceived progress - The perceived big ticket items appear to move very slowly, because they are much lower priority than day-to-day running of infra. I do have an announcement to make in the next day or 3 about some infra stuff that's going on, because it's going to affect every developer. Question for you there, you said 'overlays.g.o migration'. What migration? It moved to the new hardware more than a year ago. - Website redesign - we had a contest some years ago, got a winner, someone started to adapt the design and somewhat that project fall asleep. The guy that was doing the redesign changes vanished for a long time, he's been around again lately however. So - what to do now? To be honest - I have no real clue. But a first step might be to collect your opinions on where we do lack manpower and ideas on how to solve this problems. A Wiki might be fitting well for that task *cough*. A next step might be to discuss every identified problem and discuss our options and ideas how to improve the situation. Discussion on wiki has been going on for a while, I'll come, in a couple of months probably, but I still haven't heard anything of my call for people that were willing to do the work of editors and spam removal. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Is Gentoo a Phoenix?
On 04/03/10 11:16, Tobias Scherbaum wrote: Hell no, but ... We have lots of quite understaffed areas, to sum up in a positive way. Summing it up the negative way one might say, we have lots of areas were users might get the idea Gentoo already is dead. So what are _you_ doing to make it better? For example: - hardened-sources are nowadays only available in an experimental overlay, lots of users keep asking what's happening to the hardened-sources on both the -dev but also the -hardened mailinglist. Yeah, we do have people working on hardened stuff, but if people just take what's happening in the portage tree they might think that the hardened stuff they're relying on for their business isn't supported any longer. With Zorry we just got a new recruit for working on hardened things, especially toolchain. It's not as dead as you make it sound ... - Our formerly outstanding documentation still is somewhat maintained, but that's it. I haven't seen any new additions (both to our docs, but also to our docs-team) for years. People are constantly asking for a documentation wiki, but ... yeah, as long as no one just creates a wiki there won't be one. People are waiting on other people, who are waiting for Godot. Just do it. I remember the long and whiny road to get a blog aggregator - what killed the waiting deadlock was simply karltk setting up one (unofficial etc.etc.) and suddenly people saw that it was good. - Understaffed herds: For example net-mail, netmon and others - were missing lots of developers and their support in lots of areas. Sadly those areas are mostly those ones, one might need packages for their business servers from. And still, when someone tries to fix things in such an understaffed herd people go all territorial and are like omg u touched my package. Right now I'm quite confused what our project strategy seems to be, as far as I can tell there's one group aiming for an aesthetical optimum and the other group just wants to get things fixed. And they are not cooperating well ... So - what to do now? For me it's simple. I try to - dedicate time to fixing things. Takes lots of time, can be demotivating - try to motivate and recruit new users - hard to motivate them, and with our current recruiting setup it's hard to keep them motivated - not get demotivated by the OMG it's all bad attitude some people radiate And don't just start discussing how to discuss things. That's not going to work. You'll end up with a pretty specific plan how to discuss the whole thing, then get bored and not discuss it at all. Just start fixing things. Set yourself some personal goals (do on average one commit a day? fix one bug a day?) and try to reach them. If you do, set yourself some new goals. I have found some pretty amazing proxy-maintainers in the last weeks, there's quite a lot of progress happening. There's still lots of potential, but most people only start interacting with us once we have started to show some activity. Right now we might be in a not-that-excellent position, but it won't just go away. It needs all of us to _do_ something. wkr, Patrick
Re: [gentoo-dev] Is Gentoo dying?
On Sat, Apr 03, 2010 at 09:40:12AM +, Robin H. Johnson wrote: So - what to do now? To be honest - I have no real clue. But a first step might be to collect your opinions on where we do lack manpower and ideas on how to solve this problems. A Wiki might be fitting well for that task *cough*. A next step might be to discuss every identified problem and discuss our options and ideas how to improve the situation. Discussion on wiki has been going on for a while, I'll come, in a couple of months probably, but I still haven't heard anything of my call for people that were willing to do the work of editors and spam removal. It'll come. That typo sucked. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I would like to avoid things like this: https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 Not applicable to the bug above but in general our social contract says: We will not hide problems Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On 04/03/10 10:50, Petteri Räty wrote: I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I would like to avoid things like this: https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 Not applicable to the bug above but in general our social contract says: We will not hide problems Sounds good, can we at the same time get RESOLVED OBSOLETE (for bugs that are not valid anymore due to changed situation, RESOLVED INVALID isn't applicable in this case as it implies the bug is and was invalid from the begining). When we kill RESOLVED LATER maybe we could also kill RESOLVED REMIND? I don't remember it being very useful. -- Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On 4/3/10 12:03 PM, Krzysztof Pawlik wrote: On 04/03/10 10:50, Petteri Räty wrote: I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I would like to avoid things like this: https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 Not applicable to the bug above but in general our social contract says: We will not hide problems Sounds good, can we at the same time get RESOLVED OBSOLETE (for bugs that are not valid anymore due to changed situation, RESOLVED INVALID isn't applicable in this case as it implies the bug is and was invalid from the begining). Wouldn't WORKSFORME apply in that case? Just renaming the resolutions doesn't gain us much. Reducing the number of possible resolutions does, I'd say. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Is Gentoo dying?
Am Samstag, den 03.04.2010, 02:37 -0700 schrieb Brian Harring: On Sat, Apr 03, 2010 at 11:16:32AM +0200, Tobias Scherbaum wrote: Hell no, but ... Then avoid feeding the distrowatch trolls w/ sensational subjects please ;) oh, well ;) We have lots of quite understaffed areas, to sum up in a positive way. Summing it up the negative way one might say, we have lots of areas were users might get the idea Gentoo already is dead. Got any metrics offhand? The reason I ask is that I can't think of a time when 'understaffed' wasn't an applicable term. Metrics are a problem and i'm pretty sure you won't get any somewhat correct metrics as we have lots of herds which do have some developers listed as herd members, who are mia for quite some time. Still when considering herd members who did a commit to a package belonging to given herd in the past say 4 weeks as active you won't get useful metrics. Sidenote, if we *aren't* tracking the basics, it might be worthwhile. Shouldn't be too hard to grab the history of herds.xml for example and extract the relevant data. One thing to note... crappy support for something can draw people out to contribute. Hence asking about metrics- I wouldn't be surprised if the headcount for misc. projects is a cyclic rise/fall. At the very least I'd be curious about the pre and post git metrics, once that conversion is finished up. - Infra: One might get the idea our Infra team is just Robin (yeah, sure there are more people, but ) ... things are happening slowly (no offend - I fully understand that those few can't dedicate more of their spare time to infra work!), take overlays.g.o migration, Bugzie-3 migration and so on as an example. Relaying from IRC, overlays.g.o migration bits seem to be done... Yeah, probably i had something wrong in mind. Nevermind. Tbh, my intention wasn't to discuss the _examples_ i listed, but to hear all your opinions and ideas on where we do have problems and how to solve them. - Website redesign - we had a contest some years ago, got a winner, someone started to adapt the design and somewhat that project fall asleep. A status update on this one would be useful, even if it's just got no time, here's what is remaining so someone could jump in and help where possible. Personally I'd suggest trying to extract status updates from folk- it's more useful anyways to know what's needed to get various projects done. Yeah, status updates++ ... at least active projects/herds (like what Robin said about Infra) would be considered more active then :) - Tobias -- Praxisbuch Nagios http://www.oreilly.de/catalog/pbnagiosger/ https://www.xing.com/profile/Tobias_Scherbaum signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Is Gentoo dying?
Am Samstag, den 03.04.2010, 11:26 +0200 schrieb Paweł Hajdan, Jr.: For example: - hardened-sources are nowadays only available in an experimental overlay, lots of users keep asking what's happening to the hardened-sources on both the -dev but also the -hardened mailinglist. I recently sent an e-mail to gentoo-dev, http://archives.gentoo.org/gentoo-dev/msg_2eb703ee97afc64a29e5d148457ac8d5.xml Yeah, seen that. It seems that some work is being done, but there are people who volunteered to help, like me. What needs to be done with hardened-sources? Just a note: I'm using it on my servers, so I'm really interested in them being maintained, and I'm also able to test. See - what we've been doing with people like you who are willing to contribute was something like Hey, nice to see you. Get in touch with the correct people, please - and i'm pretty sure there are many options on how to improve our handling of people like you, who are willing to contribute some amount of time to the Gentoo Project. - Tobias -- Praxisbuch Nagios http://www.oreilly.de/catalog/pbnagiosger/ https://www.xing.com/profile/Tobias_Scherbaum signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Is Gentoo a Phoenix?
Am Samstag, den 03.04.2010, 11:46 +0200 schrieb Patrick Lauer: We have lots of quite understaffed areas, to sum up in a positive way. Summing it up the negative way one might say, we have lots of areas were users might get the idea Gentoo already is dead. So what are _you_ doing to make it better? I started to maintain those unmaintained packages which are important to me myself and ended up in the net-mail/netmon herds for example. Postfix, Cyrus-Imap, Bind, Nagios and several others are packages i put my hands on - just because noone else did and those were and still are essential to me. - hardened-sources are nowadays only available in an experimental overlay, lots of users keep asking what's happening to the hardened-sources on both the -dev but also the -hardened mailinglist. Yeah, we do have people working on hardened stuff, but if people just take what's happening in the portage tree they might think that the hardened stuff they're relying on for their business isn't supported any longer. With Zorry we just got a new recruit for working on hardened things, especially toolchain. It's not as dead as you make it sound ... Good to see there's something happening in hardened - but still, the user outside of Gentoo still only is seeing: Oh, no hardened-sources update for nearly a year. - Understaffed herds: For example net-mail, netmon and others - were missing lots of developers and their support in lots of areas. Sadly those areas are mostly those ones, one might need packages for their business servers from. And still, when someone tries to fix things in such an understaffed herd people go all territorial and are like omg u touched my package. Right now I'm quite confused what our project strategy seems to be, as far as I can tell there's one group aiming for an aesthetical optimum and the other group just wants to get things fixed. And they are not cooperating well ... I for one can't say I had any territorial problems when touching packages belonging to other devs or herds - it's just a problem if you screw up. - Tobias -- Praxisbuch Nagios http://www.oreilly.de/catalog/pbnagiosger/ https://www.xing.com/profile/Tobias_Scherbaum signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On 04/03/10 11:09, Paweł Hajdan, Jr. wrote: On 4/3/10 12:03 PM, Krzysztof Pawlik wrote: On 04/03/10 10:50, Petteri Räty wrote: I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I would like to avoid things like this: https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 Not applicable to the bug above but in general our social contract says: We will not hide problems Sounds good, can we at the same time get RESOLVED OBSOLETE (for bugs that are not valid anymore due to changed situation, RESOLVED INVALID isn't applicable in this case as it implies the bug is and was invalid from the begining). Wouldn't WORKSFORME apply in that case? Just renaming the resolutions doesn't gain us much. Reducing the number of possible resolutions does, I'd say. In my opinion: no. WORKSFORME is for a problems that can't be reproduced. OBSOLETE would be: yes, this bug has been applicable, but situation changed, ignore it. One of the examples could be stabilization bugs: you have an open stabilization bug, but new version comes out with important security fix and it needs to go stable ASAP. You mark the old stabilization bug as OBSOLETE and continue in the one opened for security issue (as it usually happens). To summarize: I'm suggesting axing two resolutions (LATER and REMIND) and introduce OBSOLETE. If OBSOLETE doesn't sound like a good idea I'm ok with not having it -- removing two resolutions is a nice achievement too :) -- Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
* Alec Warner anta...@gentoo.org: It is obvious what many of the functions do (I can read shell, yay!) but it is not obvious to me why they exist or why I would want to call them. Why do I want to delete AppleDouble files? What are dual-life scripts and why do I want to symlink them? Why would I want to delete packfiles? Some documentation would be nice h ere. Absolutely. The perl-team already has a bug for it (#259815). Perl eclass changes are tracked in bug #239510. But I don't think missing documentation is a stopper here. Most of it is copied from perl-modules.eclass. - AppleDouble (name reported by `file`) 268497 [p...@gentoo.org] - Remove ._* files in perl-module_src_prepare 273104 [dev-port...@gentoo.org] - New QA check: installed OSX fork files (if I got the name right) - dual-life scripts scripts installed by dual-life packages (part of dev-lang/perl and also stand-alone in perl-core/). Only relevant for perl-core/ packages. - .packlist something like CONTENTS. [---=| TOFU protection by t-prot: 143 lines snipped |=---]
[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
* James Cloos cl...@jhcloos.com: One change the perl eclasses require is elimination of the code which deletes the man pages. Deleting the man pages is /extremely/ rude and should not occur. There was a reason why the man-pages were removed: I think it was collisions protection and perl people use `perldoc` anyway. Do we need a patch to avoid collisions? Do you have it ready and tested?
[gentoo-dev] [RFC] More reliable hiding preserved libraries
Problem
..is known, let me summarize briefly.
Uninstalling packages providing libraries, without checking reverse runtime
dependencies of those packages leaves their dependencies unsatisfied (packages
with broken executables and/or shared libs).
Some package managers try their best not to remove said libraries, yet
allowing packages to be removed.
Those orphaned libraries cause problems[1] as build systems of some other
packages being (re)installed afterwards pick them up and abuse those orphaned
libraries. (we don't like orphans abused, we prefer them... gone).
Solution
Now, I suppose there are some ideas how to make orphaned libraries not go in a
way. Basically then need to be available for system, but hidden for emerge.
There is opt-out suggestion[2], unfortunately it does not provide any info how
exactly it's supposed to be achieved. As far as portage/pkgcore is concerned,
maybe - as Brian Harring suggested - sandbox could be used to somehow hide
preserved libraries or preserved library directory from ebuild environment
(preserved library directory a'ka purgatory - libs could be moved there when
considered orphaned).
Opt-in suggestion is as follows:
1. Use some library path (read by ld loader from environment) and export it
globally to environment pointing it to preserved library directory.
2. During emerge, unset environment variable corresponding to said preserved
library directory - orphans are no longer located.
Attached patch for glibc (2.11, but should apply to any other glibc around)
and uClibc (this one is not tested but should work as well) that makes ld
loader aware of LD_GENTOO_PRESERVED_LIBRARY_PATH variable.
(LD_LIBRARY_PATH would work as well, but it's being used widely so cannot be
safely mangled.. on the second though it can - one could filter out preserved
library paths from it during emerge).
Thoughts?
1. https://bugs.gentoo.org/show_bug.cgi?id=240323
2. https://bugs.gentoo.org/show_bug.cgi?id=307391
--
regards
MM
diff -ru ../glibc-2.11/elf/rtld.c ./elf/rtld.c
--- ../glibc-2.11/elf/rtld.c 2009-10-30 18:17:08.0 +0100
+++ ./elf/rtld.c 2010-04-03 10:51:46.468906521 +0200
@@ -874,6 +874,8 @@
/* The library search path. */
static const char *library_path attribute_relro;
+/* Gentoo preserved library path. */
+static const char *preserved_library_path attribute_relro;
/* The list preloaded objects. */
static const char *preloadlist attribute_relro;
/* Nonzero if information about versions has to be printed. */
@@ -1385,7 +1387,18 @@
/* Initialize the data structures for the search paths for shared
objects. */
- _dl_init_paths (library_path);
+ char *llp = alloca ((library_path != NULL ? strlen (library_path) : 0) +
+(preserved_library_path != NULL ? strlen (preserved_library_path) : 0) + 2);
+ *llp = '\0';
+ if (library_path != NULL)
+{
+ strcat (llp, library_path);
+ if (preserved_library_path != NULL)
+strcat (llp, :);
+}
+ if (preserved_library_path != NULL)
+strcat (llp, preserved_library_path);
+ _dl_init_paths (llp);
/* Initialize _r_debug. */
struct r_debug *r = _dl_debug_initialize (GL(dl_rtld_map).l_addr,
@@ -2648,6 +2661,16 @@
mode = trace;
break;
+ case 29:
+ /* Read Gentoo preserved library path from env here. Watch out for
+ possible future 'case' additions in this switch as well as in
+ EXTRA_LD_ENVVARS defined in sysdeps/arch/dl-librecon.h.
+ LD_GENTOO_PRESERVED_LIBRARY_PATH is blacklisted for SUID
+ programs in sysdeps/generic/unsecvars.h. */
+ if (memcmp (envline, GENTOO_PRESERVED_LIBRARY_PATH, 29) == 0)
+ preserved_library_path = envline[30];
+ break;
+
/* We might have some extra environment variable to handle. This
is tricky due to the pre-processing of the length of the name
in the switch statement here. The code here assumes that added
diff -ru ../glibc-2.11/sysdeps/generic/unsecvars.h ./sysdeps/generic/unsecvars.h
--- ../glibc-2.11/sysdeps/generic/unsecvars.h 2009-10-30 18:17:08.0 +0100
+++ ./sysdeps/generic/unsecvars.h 2010-04-03 10:48:07.192280437 +0200
@@ -10,6 +10,7 @@
LD_DEBUG_OUTPUT\0 \
LD_DYNAMIC_WEAK\0 \
LD_LIBRARY_PATH\0 \
+ LD_GENTOO_PRESERVED_LIBRARY_PATH\0 \
LD_ORIGIN_PATH\0 \
LD_PRELOAD\0 \
LD_PROFILE\0 \
diff -ru ../uClibc-0.9.30.1/ldso/include/dl-hash.h ./ldso/include/dl-hash.h
--- ../uClibc-0.9.30.1/ldso/include/dl-hash.h 2008-11-03 16:41:17.0 +0100
+++ ./ldso/include/dl-hash.h 2010-04-03 11:23:44.026291507 +0200
@@ -132,6 +132,7 @@
extern int _dl_linux_dynamic_link(void);
extern char * _dl_library_path;
+extern char * preserved_library_path;
extern char * _dl_not_lazy;
static __inline__ int _dl_symbol(char * name)
diff -ru ../uClibc-0.9.30.1/ldso/include/ldso.h ./ldso/include/ldso.h
--- ../uClibc-0.9.30.1/ldso/include/ldso.h 2008-05-30 16:35:31.0 +0200
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Sat, Apr 03, 2010 at 12:38:17PM +0200, Maciej Mrozowski wrote: exactly it's supposed to be achieved. As far as portage/pkgcore is concerned, maybe - as Brian Harring suggested - sandbox could be used to somehow hide preserved libraries or preserved library directory from ebuild environment (preserved library directory a'ka purgatory - libs could be moved there when considered orphaned). When I've tried experimenting w/ this I've had zero luck in intercepting lib loadup on that one. ~harring pgpoGunNZ7rNI.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On 03-04-2010 12:38:17 +0200, Maciej Mrozowski wrote: Problem ..is known, let me summarize briefly. Uninstalling packages providing libraries, without checking reverse runtime dependencies of those packages leaves their dependencies unsatisfied (packages with broken executables and/or shared libs). Some package managers try their best not to remove said libraries, yet allowing packages to be removed. Those orphaned libraries cause problems[1] as build systems of some other packages being (re)installed afterwards pick them up and abuse those orphaned libraries. (we don't like orphans abused, we prefer them... gone). Is it known why this does happen exactly? When a lib is kept because it is still used, only its soname + what the soname points to should be kept. That would mean the lib can no longer be found during linking, unless you add some trickery (or does GNU ld do something handy out of the box right here?). So for example: % ls usr/lib/libfoo.so - libfoo.so.2.1 usr/lib/libfoo.so.2 - libfoo.so.2.1 usr/lib/libfoo.so.2.1 % scanelf --soname usr/lib/libfoo.so libfoo.so.2 usr/lib/libfoo.so what should kept preserved is: usr/lib/libfoo.so.2 - libfoo.so.2.1 usr/lib/libfoo.so.2.1 because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should (in theory and on some platforms at least) fail. Solution Now, I suppose there are some ideas how to make orphaned libraries not go in a way. Basically then need to be available for system, but hidden for emerge. There is opt-out suggestion[2], unfortunately it does not provide any info how exactly it's supposed to be achieved. As far as portage/pkgcore is concerned, maybe - as Brian Harring suggested - sandbox could be used to somehow hide preserved libraries or preserved library directory from ebuild environment (preserved library directory a'ka purgatory - libs could be moved there when considered orphaned). Opt-in suggestion is as follows: 1. Use some library path (read by ld loader from environment) and export it globally to environment pointing it to preserved library directory. you mean: move preserved libs to some special place and have that place being found at runtime somehow? 2. During emerge, unset environment variable corresponding to said preserved library directory - orphans are no longer located. Attached patch for glibc (2.11, but should apply to any other glibc around) and uClibc (this one is not tested but should work as well) that makes ld loader aware of LD_GENTOO_PRESERVED_LIBRARY_PATH variable. (LD_LIBRARY_PATH would work as well, but it's being used widely so cannot be safely mangled.. on the second though it can - one could filter out preserved library paths from it during emerge). In general, LD_LIBRARY_PATH is considered harmful, and I wouldn't like to see it being used for normal operation. Instead I'd like to know first why applications can find retained libs, because from the Portage side, in theory they shouldn't. Maybe patching GNU ld if it turns out being too smart may solve problems in a nicer way. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Sat, 3 Apr 2010 12:38:17 +0200 Maciej Mrozowski reave...@gmail.com wrote: 2. During emerge, unset environment variable corresponding to said preserved library directory - orphans are no longer located. Wouldn't that cause failure when the toolkit relies on a 'hidden' preserved library? -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
[gentoo-dev] spin (spinroot.com) license
I'd like to add a package for spin to the tree (it's used at several universities, including mine and Caltech). However, it's not straightforward. The basic license is for educational purposes only. Here are my suggestions how to implement that. /usr/portage/licenses/spin-educational with the following content: Copyright (c) 1989-2006 Lucent Technologies, Bell Labs Extensions (c) 2006-2009 NASA/JPL California Institute of Technology All Rights Reserved. For educational purposes only. No guarantee whatsoever is expressed or implied by the distribution of this code. /usr/portage/licenses/spin-commercial with the content pasted from http://www.spinroot.com/spin/spin_license.html And then in the ebuild: LICENSE=|| ( spin-educational spin-commercial ) Are there any license groups these should be added to? signature.asc Description: OpenPGP digital signature
[gentoo-dev]
www.medicationsshop.refytopls.com
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
Le samedi 03 avril 2010 à 12:38 +0200, Maciej Mrozowski a écrit : There is opt-out suggestion[2], unfortunately it does not provide any info how exactly it's supposed to be achieved. As far as portage/pkgcore is concerned, maybe - as Brian Harring suggested - sandbox could be used to somehow hide preserved libraries or preserved library directory from ebuild environment (preserved library directory a'ka purgatory - libs could be moved there when considered orphaned). that sounds nice, it would allow us to more easily spot packages/upstreams doing it wrong (maybe that would work for packages linking to themselves too btw) -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] Is Gentoo a Phoenix?
On 04/03/2010 06:19 AM, Tobias Scherbaum wrote: And still, when someone tries to fix things in such an understaffed herd people go all territorial and are like omg u touched my package. Right now I'm quite confused what our project strategy seems to be, as far as I can tell there's one group aiming for an aesthetical optimum and the other group just wants to get things fixed. And they are not cooperating well ... I for one can't say I had any territorial problems when touching packages belonging to other devs or herds - it's just a problem if you screw up. Agreed - if you ping the herd in advance, and get an OK (or at least no reply for a few days), and then you make some simple fixes to their packages, it is very unlikely that you're going to have any complaints. If you send the the proposed patch in advance and let them review it, and you get no complaints, you're even more clearly in the right. If you don't notify them at all, or you notify them and do a cvs commit 3 minutes later, or if you completely redesign their ebuilds in addition to fixing a 1-line problem, then you're going to get complaints. Nobody minds help. People do mind when somebody drops by to help them for 5 minutes and they're stuck with the aftermath. We don't own our packages, but existing maintainers have at least shown a long-term commitment to them (however strong) and that should at least be respected. On other topics in this thread: I agree wholeheartedly that whenever possible just do it is a good approach - especially when you're talking about documentation and external websites/etc. Modifications to things that already exist are less amenable to just do it. I really think that the Gentoo recruitment process needs improvement. Right now it seems like a LOT of effort is required both to become a Gentoo dev and to help somebody become a Gentoo dev. That means we have great people, but not many of them. I think the problem is that our recruitment process uses the ability to answer complex technical and organizational questions as a way to assess maturity. I think that maturity is far more important than technical skill in a distro - a mature person will recognize their own limitations and exercise due diligence when stepping outside of them. Instead of playing 20 questions and going back and forth with recruits, maybe a better approach would be to cut down the questions dramatically (or more clearly put their answers in the documentation), and then use other approaches like references and interviews. A new recruit might be given the names of 5 devs that they will need to interview with for 30-60 minutes by phone or IRC (preference on phone), and they will need to submit references, who will be contacted. When we hire people at work we don't play trivial pursuit with them, we use an interview to get a feel for what they're like and how they handle situations, and we screen resumes and references to determine experience. I'm sure any of the professional linux distros would work in the same way, but perhaps somebody should ask around and see how it is done elsewhere. So, now instead of a recruiter having to spend hours helping somebody through quizzes without giving them answers, instead they just send them a list of interviewers, and collate the results. Any interviewer will just need to spend 30 minutes on an interview and 10 minutes on a writeup. Plus, the whole process will make Gentoo a bit more human. Rich
hardened-sources development (was: Re: [gentoo-dev] Is Gentoo dying?)
Am 03.04.2010 11:26, schrieb Paweł Hajdan, Jr.: On 4/3/10 11:16 AM, Tobias Scherbaum wrote: Hell no, but ... We have lots of quite understaffed areas, to sum up in a positive way. Summing it up the negative way one might say, we have lots of areas were users might get the idea Gentoo already is dead. For example: - hardened-sources are nowadays only available in an experimental overlay, lots of users keep asking what's happening to the hardened-sources on both the -dev but also the -hardened mailinglist. I recently sent an e-mail to gentoo-dev, http://archives.gentoo.org/gentoo-dev/msg_2eb703ee97afc64a29e5d148457ac8d5.xml It seems that some work is being done, but there are people who volunteered to help, like me. What needs to be done with hardened-sources? Just a note: I'm using it on my servers, so I'm really interested in them being maintained, and I'm also able to test. Most development of hardened-sources was done in hardened-development overlay. There are currently recent versions of hardened-sources, but they have some regressions, which should be fixed, before they are added to the main tree. If you want to help out with this package, i suggest you join #gentoo-hardened on freenode, since that is the place, where most of the conversation is done. Additionally it might have been better to send this mail at least in CC to gentoo-hardened ML, since most interested and active people are only subscribed there. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Is Gentoo a Phoenix?
On 04/03/2010 02:33 PM, Richard Freeman wrote: I think the problem is that our recruitment process uses the ability to answer complex technical and organizational questions as a way to assess maturity. I think that maturity is far more important than technical skill in a distro - a mature person will recognize their own limitations and exercise due diligence when stepping outside of them. Instead of playing 20 questions and going back and forth with recruits, maybe a better approach would be to cut down the questions dramatically (or more clearly put their answers in the documentation), and then use other approaches like references and interviews. A new recruit might be given the names of 5 devs that they will need to interview with for 30-60 minutes by phone or IRC (preference on phone), and they will need to submit references, who will be contacted. When we hire people at work we don't play trivial pursuit with them, we use an interview to get a feel for what they're like and how they handle situations, and we screen resumes and references to determine experience. I'm sure any of the professional linux distros would work in the same way, but perhaps somebody should ask around and see how it is done elsewhere. The sessions also teach them a lot. I regularly get feedback that people learned a lot during the sessions. Reading a lot of technical documentation doesn't motivate many but the reviews do. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Saturday 03 of April 2010 12:56:04 Fabian Groffen wrote: Is it known why this does happen exactly? When a lib is kept because it is still used, only its soname + what the soname points to should be kept. That would mean the lib can no longer be found during linking, unless you add some trickery (or does GNU ld do something handy out of the box right here?). So for example: % ls usr/lib/libfoo.so - libfoo.so.2.1 usr/lib/libfoo.so.2 - libfoo.so.2.1 usr/lib/libfoo.so.2.1 % scanelf --soname usr/lib/libfoo.so libfoo.so.2 usr/lib/libfoo.so what should kept preserved is: usr/lib/libfoo.so.2 - libfoo.so.2.1 usr/lib/libfoo.so.2.1 because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should (in theory and on some platforms at least) fail. It doesn't matter, as 'broken' build system may alphabetically find library by file name, and link to this library by full path. On Saturday 03 of April 2010 13:13:00 Michał Górny wrote: 2. During emerge, unset environment variable corresponding to said preserved library directory - orphans are no longer located. Wouldn't that cause failure when the toolkit relies on a 'hidden' preserved library? It would indeed. Now when I think about it, moving stuff to preserved library dir could be just done - provided it's possible - along with fixing/setting DT_RPATH's in reverse runtime dependencies. This way no system-wide LIBRARY_PATH's would be necessary. Is it possible? Mike? On Saturday 03 of April 2010 13:33:16 Gilles Dartiguelongue wrote: There is opt-out suggestion[2], unfortunately it does not provide any info how exactly it's supposed to be achieved. As far as portage/pkgcore is concerned, maybe - as Brian Harring suggested - sandbox could be used to somehow hide preserved libraries or preserved library directory from ebuild environment (preserved library directory a'ka purgatory - libs could be moved there when considered orphaned). that sounds nice, it would allow us to more easily spot packages/upstreams doing it wrong (maybe that would work for packages linking to themselves too btw) Keeping preserved libraries in separate location (in purgatory or dumping place) is just a method for making implementation possibly easier (or possible at all), with nice side effects though. -- regards MM
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On 03-04-2010 14:09:42 +0200, Maciej Mrozowski wrote: because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should (in theory and on some platforms at least) fail. It doesn't matter, as 'broken' build system may alphabetically find library by file name, and link to this library by full path. Shouldn't we fix that buildsystem then? Do you have an example of a package/buildsystem that does that? On Saturday 03 of April 2010 13:13:00 Michał Górny wrote: 2. During emerge, unset environment variable corresponding to said preserved library directory - orphans are no longer located. Wouldn't that cause failure when the toolkit relies on a 'hidden' preserved library? It would indeed. Now when I think about it, moving stuff to preserved library dir could be just done - provided it's possible - along with fixing/setting DT_RPATH's in reverse runtime dependencies. This way no system-wide LIBRARY_PATH's would be necessary. Is it possible? Mike? No, unless you somehow make sure you reserve space for this, by e.g. setting a bogus rpath entry at buildtime. If you want to go that route, you probably want to look at the Prefix' binutils-config wrapper that already calls the linker with added rpath arguments. Afterwards you can use chrpath to set it to the correct location. Will get messy with the vdb though, but if Portage's doing it, it can probably be dealt with. -- Fabian Groffen Gentoo on a different level
[gentoo-dev][Gentoo Phoenix] Re: Is Gentoo a Phoenix?
On 3 April 2010 11:46, Patrick Lauer patr...@gentoo.org wrote: On 04/03/10 11:16, Tobias Scherbaum wrote: Hell no, but ... We have lots of quite understaffed areas, to sum up in a positive way. Summing it up the negative way one might say, we have lots of areas were users might get the idea Gentoo already is dead. So what are _you_ doing to make it better? I like that attitude! And I'm so going to steal your idea about the phoenix. I'll start using the [Gentoo Phoenix] tag for discussions about how we can make Gentoo better. Maybe we could even start a project for it, trying to bring together ideas and people who want to improve things. I have several things I wanted to start a discussion about already, and it seems these things are in the air now as I see these topics popping up left and right now. I'll fork off from this discussion into some specific things in order to try to keep things a bit organized. So - what to do now? For me it's simple. I try to - dedicate time to fixing things. Takes lots of time, can be demotivating As I've recently refocussed my Gentoo activities on Qt, and withdrawn from various other herds I was involved in, I now have some time and motivation to pick up something new. I wish to dedicate this to something that will really help and I believe these discussions are a good starting point. I hope it will trigger others in similar ways. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] Is Gentoo a Phoenix?
lördag 03 april 2010 12.19.19 skrev Tobias Scherbaum: - hardened-sources are nowadays only available in an experimental overlay, lots of users keep asking what's happening to the hardened-sources on both the -dev but also the -hardened mailinglist. Yeah, we do have people working on hardened stuff, but if people just take what's happening in the portage tree they might think that the hardened stuff they're relying on for their business isn't supported any longer. With Zorry we just got a new recruit for working on hardened things, especially toolchain. It's not as dead as you make it sound ... Good to see there's something happening in hardened - but still, the user outside of Gentoo still only is seeing: Oh, no hardened-sources update for nearly a year. How long did it take for Hardened GCC to move to 4.X? And we are still lacking SSP support in the tree. We have lost almost all dev's in the herd the past years. As for hardened-sources we are working on it but that work has not hit the tree yet and that not a good situation. It will hit the tree soner or later. We work on our free time to and we don't have all the free time in the world to work on it. There is a long todo list. It is very time comsuming work on the toolchain, kernel, docs, bugs, recruit and help users at the same time. As tree dev that do all the work but we have users and some devs that help out too and that we are thankful for ther help. Hopefully we have something on the hardened-sources after next meeting. @ Paweł Hajdan, Jr. you could ask in hardened-ker...@gentoo.org what thay need for help or join #gentoo-hardened @ freenode.net And the hardened-sources in the hardened-development overlay have some regreesions that we are working on to fix. Sorry if i bing roude. Hardened at gentoo.org Magnus Granberg (Zorry) zo...@gentoo.org
[gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 3 April 2010 11:46, Patrick Lauer patr...@gentoo.org wrote: On 04/03/10 11:16, Tobias Scherbaum wrote: People are constantly asking for a documentation wiki, but ... yeah, as long as no one just creates a wiki there won't be one. People are waiting on other people, who are waiting for Godot. Just do it. I remember the long and whiny road to get a blog aggregator - what killed the waiting deadlock was simply karltk setting up one (unofficial etc.etc.) and suddenly people saw that it was good. Okay, so it seems a lot of people do want a wiki. So let's see what we can do to make that happen. 1 - requirements In order to choose the best possible wiki implementation, we need to know our requirements. So what features do you think are essential or good to have? What syntax would we prefer to use? I myself am a big fan of reStructuredText, which is quite simple, easy to pick up, highly readable, and has a good featureset. Plus, it is also reusable in other contexts (it is for example widely used in documentation of Python libraries). MediaWiki, MoinMoin and Trac have support for rst. Some others: - active upstream (bug fixes, security updates) - free open source software - ACLs - spam prevention measures - attachments (to upload screenshots for example) - feeds Other distros and open source projects surely have had the same considerations. Can we find out and learn from them? 2 - maintainers === Who is volunteering for maintaining the wiki? We need editors and moderators, people who look out for quality control and take care of spam removal. So let's get together a team. I'm sure if we ask on the forums we'll get some users interested as well. 3 - edit access === Do we keep to the original free for all model, with all the spam that includes, or do we go with registered users only? I think the latter is the smarter option. I also think we will want to mark certain pages official and lock down editing rights. Is there anything else we should consider before getting started? Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
[gentoo-dev] [Gentoo Phoenix] recruitment process
On 3 April 2010 13:33, Richard Freeman ri...@gentoo.org wrote: I really think that the Gentoo recruitment process needs improvement. Right now it seems like a LOT of effort is required both to become a Gentoo dev and to help somebody become a Gentoo dev. That means we have great people, but not many of them. I agree. So what can we do to improve this process? I myself am not fond of the quizzes, and from what I've seen most recruits find them tedious as well. It can be quite demotivating, maybe because it reminds one too much of highschool or something. I took a long time myself to finish them, and that wouldn't have been necessary, as my mentors ensured me I was ready to become a dev. And I see the same thing happening with some of my own recruits. They can be ready, but just find the quizzes a chore. So I think we need to rethink how to do this. What I have found very helpful is to have my recruits working on actual ebuilds. The sunrise project is ideally qualified to mold ebuild editors into shape. Working on official overlays such as qting-edge and/or doing proxy maintenance is also very helpful. Recruiters (with some additional manpower) could make a list of technical issues that recruits need to be aware of, and then gather a number of ebuilds that display these problems and let recruits correct some of these, under guidance of their mentors. This may possibly be more fun and closer to the actual work that is required of developers. Of course this doesn't address the organizational side of things, so we need to come up with something else for that. Another problem I see is that our documentation seems to be scattered all over the place. I propose that we make at least one portal page for (prospective) developers that will link them to all the resources they might need. It also means our existing documentation needs to be brought and kept up to date. Are there any other ideas on how to improve our recruitment process? -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sat, Apr 3, 2010 at 16:19, Ben de Groot yng...@gentoo.org wrote: 1 - requirements In order to choose the best possible wiki implementation, we need to know our requirements. So what features do you think are essential or good to have? What syntax would we prefer to use? I myself am a big fan of reStructuredText, which is quite simple, easy to pick up, highly readable, and has a good featureset. Plus, it is also reusable in other contexts (it is for example widely used in documentation of Python libraries). MediaWiki, MoinMoin and Trac have support for rst. Some others: - active upstream (bug fixes, security updates) - free open source software - ACLs - spam prevention measures - attachments (to upload screenshots for example) - feeds There is currently a wiki for gentoo at gentoo-wiki.com, which is running MediaWiki, so it would be easiest to transfer the content if we were to run the same software. Now, this doesn't mean we should be limited by their actions, but it seems to me like the best choice for other reasons as well. Its syntax is probably the most well known, thanks to Wikipedia. Its upstream is active, it apparently scales and performs pretty well, it's GPL, supports translations/localization, feeds, attachments, etc. I'm sure many other alternatives are as qualified, so this is most likely a personal preference issue. As such, lets just agree on something that works and is widespread and go with that and avoid all the bikeshedding. 2 - maintainers === Who is volunteering for maintaining the wiki? We need editors and moderators, people who look out for quality control and take care of spam removal. So let's get together a team. I'm sure if we ask on the forums we'll get some users interested as well. I volunteer. Spam shouldn't be that much of an issue if editing is restricted to registered users, but it is a good idea to have a team of moderators similar to the one that exists for the forums (of course users can take part of it as well as developers). 3 - edit access === Do we keep to the original free for all model, with all the spam that includes, or do we go with registered users only? I think the latter is the smarter option. I also think we will want to mark certain pages official and lock down editing rights. IMO it's best if only registered users can edit (but registering should be easy, no bugs to file or anything, just sign up and use immediately). This will probably prevent most kinds of spam and allow for much better tracking of editing and history, allow for banning, etc. without closing the wiki up too much. Also, from what I could tell, this is how others are managing their wiki as well (Arch and Amarok, for example). Dror Levin
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 4/3/10 3:40 PM, Ben de Groot wrote: Are there any other ideas on how to improve our recruitment process? The idea appeared before, but I think it's worth noting. Either merge the ebuild and end quizzes, or make the split actually meaningful. In my case I just finished both at the same time, but was confused why they are separate. I think I've seen similar comments from other developers. I think I'd rather prefer merging the quizzes. Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 03/04/2010 14:40, Ben de Groot wrote: On 3 April 2010 13:33, Richard Freemanri...@gentoo.org wrote: I really think that the Gentoo recruitment process needs improvement. Right now it seems like a LOT of effort is required both to become a Gentoo dev and to help somebody become a Gentoo dev. That means we have great people, but not many of them. I agree. So what can we do to improve this process? I myself am not fond of the quizzes, and from what I've seen most recruits find them tedious as well. It can be quite demotivating, maybe because it reminds one too much of highschool or something. I took a long time myself to finish them, and that wouldn't have been necessary, as my mentors ensured me I was ready to become a dev. And I see the same thing happening with some of my own recruits. They can be ready, but just find the quizzes a chore. So I think we need to rethink how to do this. What I have found very helpful is to have my recruits working on actual ebuilds. The sunrise project is ideally qualified to mold ebuild editors into shape. Working on official overlays such as qting-edge and/or doing proxy maintenance is also very helpful. Recruiters (with some additional manpower) could make a list of technical issues that recruits need to be aware of, and then gather a number of ebuilds that display these problems and let recruits correct some of these, under guidance of their mentors. This may possibly be more fun and closer to the actual work that is required of developers. Of course this doesn't address the organizational side of things, so we need to come up with something else for that. Another problem I see is that our documentation seems to be scattered all over the place. I propose that we make at least one portal page for (prospective) developers that will link them to all the resources they might need. It also means our existing documentation needs to be brought and kept up to date. Are there any other ideas on how to improve our recruitment process? I suggested a while ago that you should have recruitment drives and recruitment days. Set aside a day where a few devs can answer any questions about what it takes to be a developer - the skills required, the time that needs to be set aside, the behavior expected and goals that developers aspire to. Set up some threads on the forums, a channel on irc, a list like gentoo-recruitment and a FAQ on the front page of the website. Armed with a list of where developers are spread too thinly, a willingness to answer questions (no matter how stupid you believe them to be) and some prior organisation then i see no reason why Gentoo wouldn't get an immediate influx of at least 20 well-qualified developers and more that are willing to give their time and limited knowlege to help out If you build it, they will come
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 04/03/2010 04:40 PM, Ben de Groot wrote: Another problem I see is that our documentation seems to be scattered all over the place. I propose that we make at least one portal page for (prospective) developers that will link them to all the resources they might need. It also means our existing documentation needs to be brought and kept up to date. As I said elsewhere I support adding information to each question about what piece of documentation has the answer. I will get to it eventually but patches get us there faster. https://bugs.gentoo.org/show_bug.cgi?id=312977 Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Hi ! I maintain Gentoo-Québec wiki. I'm not the only one as d2_racing and some other members also do. I maintain CSS, examples and wrote almost 60% of the stuff. If you think I could help, please just let me know. The wiki : http://gentoo-quebec.org/wiki/index.php/Accueil Guy Fontaine
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 04/03/2010 04:53 PM, George Prowse wrote: Armed with a list of where developers are spread too thinly, a willingness to answer questions (no matter how stupid you believe them to be) and some prior organisation then i see no reason why Gentoo wouldn't get an immediate influx of at least 20 well-qualified developers and more that are willing to give their time and limited knowlege to help out http://www.gentoo.org/proj/en/devrel/staffing-needs/ I don't know if developers know that this page is autogenerated from individual project pages these days so it's easy for any developer to get stuff there. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 3 April 2010 16:04, Guy Fontaine guy.fonta...@videotron.qc.ca wrote: I maintain Gentoo-Québec wiki. I'm not the only one as d2_racing and some other members also do. I maintain CSS, examples and wrote almost 60% of the stuff. If you think I could help, please just let me know. I think you can help. Stay in touch! Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Am Samstag, den 03.04.2010, 16:40 +0300 schrieb Dror Levin: There is currently a wiki for gentoo at gentoo-wiki.com, which is running MediaWiki, so it would be easiest to transfer the content if we were to run the same software. This should happen (if at all) on a per article basis imho. Having the option to do so (if we want to) is a plus we should consider, though. Now, this doesn't mean we should be limited by their actions, but it seems to me like the best choice for other reasons as well. Its syntax is probably the most well known, thanks to Wikipedia. Its upstream is active, it apparently scales and performs pretty well, it's GPL, supports translations/localization, feeds, attachments, etc. I'm sure many other alternatives are as qualified, so this is most likely a personal preference issue. As such, lets just agree on something that works and is widespread and go with that and avoid all the bikeshedding. Mediawiki sounds like what we want probably, mainly because it seems to be the most popular one. Besides that: - Ubuntu and Debian are using MoinMoin - Fedora and OpenSUSE use Mediawiki 2 - maintainers === Who is volunteering for maintaining the wiki? We need editors and moderators, people who look out for quality control and take care of spam removal. So let's get together a team. I'm sure if we ask on the forums we'll get some users interested as well. I volunteer. Spam shouldn't be that much of an issue if editing is restricted to registered users, but it is a good idea to have a team of moderators similar to the one that exists for the forums (of course users can take part of it as well as developers). It's not that I'm able to invest really much time for this, but if it's needed to get this finally rolling - count me in. Plus it shouldn't be much of an issue, if editing is limited to registered users (at least when speaking of Spam). IMO it's best if only registered users can edit (but registering should be easy, no bugs to file or anything, just sign up and use immediately). This will probably prevent most kinds of spam and allow for much better tracking of editing and history, allow for banning, etc. without closing the wiki up too much. Fully ack. In addition I'd like to establish a Wiki team with both developers and experienced users who are able to review Wikipages (specifically every revision of a page) and tag those pages as reviewed. Something not that difficult, but that'll allow for some QA. See http://www.mediawiki.org/wiki/Extension:FlaggedRevs for reference. - Tobias -- Praxisbuch Nagios http://www.oreilly.de/catalog/pbnagiosger/ https://www.xing.com/profile/Tobias_Scherbaum signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 03/04/2010 15:05, Petteri Räty wrote: On 04/03/2010 04:53 PM, George Prowse wrote: Armed with a list of where developers are spread too thinly, a willingness to answer questions (no matter how stupid you believe them to be) and some prior organisation then i see no reason why Gentoo wouldn't get an immediate influx of at least 20 well-qualified developers and more that are willing to give their time and limited knowlege to help out http://www.gentoo.org/proj/en/devrel/staffing-needs/ I don't know if developers know that this page is autogenerated from individual project pages these days so it's easy for any developer to get stuff there. Looking at that page it seems clear that that is not a comprehensive list. Maybe if all herds posted who and what they require like this: Java Herd 2 people needed - Essential: Java knowlege Recommended - Javascript and ebuild writing If no-one is willing to put a plan forward then I might acquiesce to do it.
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sat, 3 Apr 2010 15:19:20 +0200, Ben de Groot yng...@gentoo.org wrote: 1 - requirements In order to choose the best possible wiki implementation, we need to know our requirements. So what features do you think are essential or good to have? What syntax would we prefer to use? [...] - active upstream (bug fixes, security updates) - free open source software - ACLs - spam prevention measures - attachments (to upload screenshots for example) - feeds I propose to use MediaWiki. It fulfills all of your points above. Plus the software is proven in large scale deployments and the security track record is alright. 2 - maintainers === Who is volunteering for maintaining the wiki? We need editors and moderators, people who look out for quality control and take care of spam removal. So let's get together a team. I'm sure if we ask on the forums we'll get some users interested as well. I'd be interested in helping out with the backend part, i.e. setting up and maintaining the Wiki software and the needed extensions, user management and support. 3 - edit access === Do we keep to the original free for all model, with all the spam that includes, or do we go with registered users only? I think the latter is the smarter option. I also think we will want to mark certain pages official and lock down editing rights. Here's another idea: The German Wikipedia uses a concept called sighted revisions. If you visit an article without logging in you will see the latest sighted revision, as an identified user you can also view the latest revision. For the editing part: Some users have the privilege to mark revisions as sighted. In Wikipedia, you gain that privilege automatically after 300 or so edits. We could of course set that bit manually or use another threshold. If a regular user makes a contribution, one of the editors would go and check the changes and mark the revision as sighted. Is there anything else we should consider before getting started? Maybe we should discuss what goals we want to reach with a Wiki. One thing is offering user-contributed documentation, of course. But do we also want a developer wiki? Or offer per-project realms in our wiki? Or $something_else? Alex signature.asc Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 3 April 2010 16:12, Tobias Scherbaum dertobi...@gentoo.org wrote: Am Samstag, den 03.04.2010, 16:40 +0300 schrieb Dror Levin: There is currently a wiki for gentoo at gentoo-wiki.com, which is running MediaWiki, so it would be easiest to transfer the content if we were to run the same software. This should happen (if at all) on a per article basis imho. Having the option to do so (if we want to) is a plus we should consider, though. This also raises the question of license. Our current documentation mostly uses the CC-BY-SA license, while the unoffical wiki adds a non-commercial restriction. By choosing one license over the other we will make copy-pasting content from the source that has the other license, as far as I can see, illegal. I would say that interchange possibilities with our existing official documentation has priority. Mediawiki sounds like what we want probably, mainly because it seems to be the most popular one. I don't think that in itself is a very good argument. Besides that: - Ubuntu and Debian are using MoinMoin - Fedora and OpenSUSE use Mediawiki I think we should consider the pros and cons of both these solutions. Does anyone have any links to the considerations that led these distros to make the choice they did? In addition I'd like to establish a Wiki team with both developers and experienced users who are able to review Wikipages (specifically every revision of a page) and tag those pages as reviewed. I agree this is a good idea. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] Is Gentoo dying?
On 2010.04.03 10:16, Tobias Scherbaum wrote: Hell no, but ... We have lots of quite understaffed areas, to sum up in a positive way. Summing it up the negative way one might say, we have lots of areas were users might get the idea Gentoo already is dead. For example: [snip lots of anecdotal evidence] - Tobias -- Praxisbuch Nagios http://www.oreilly.de/catalog/pbnagiosger/ https://www.xing.com/profile/Tobias_Scherbaum First, we need some metrics - the first step to controlling anything is to measure it. Once we have some metrics, we can prioritise. With priorities, we can identify gaps in our resource pool (not just people) and attempt to fill them with recruiting. Maybe thats a bugday topic ? An open day for users who would like to become contributors and contributors who would like to become devs. -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgpDuruiRdPW9.pgp Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 3 April 2010 16:30, Alex Legler a...@gentoo.org wrote: I propose to use MediaWiki. As I said in my other post, MediaWiki and MoinMoin should, in my opinion, be on our shortlist to consider. I'd be interested in helping out with the backend part, i.e. setting up and maintaining the Wiki software and the needed extensions, user management and support. Thanks, that would certainly be helpful. Here's another idea: The German Wikipedia uses a concept called sighted revisions. If you visit an article without logging in you will see the latest sighted revision, as an identified user you can also view the latest revision. That's an interesting idea, which we should consider. Is there anything else we should consider before getting started? Maybe we should discuss what goals we want to reach with a Wiki. One thing is offering user-contributed documentation, of course. But do we also want a developer wiki? Or offer per-project realms in our wiki? Or $something_else? Good suggestion. I think we would want to accommodate both user-contributed documentation and developer needs. For example, recently the need arose to have a wiki page for GSoC ideas. Projects may want to use it as well. I find myself using the wiki at gitorious.org (where we also host our overlay) for purposes of the Qt herd. It would also be handy for developing new documentation (it would have helped for the LXDE guide, or the Qt4 ebuild development howto) as well as keeping existing documentation up to date. GuideXML documents are often experienced as an unnecessary barrier. What else do we want it for and how would that impact organization? -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] Is Gentoo dying?
Am Samstag, den 03.04.2010, 15:40 +0100 schrieb Roy Bamford: First, we need some metrics - the first step to controlling anything is to measure it. So, how do you want to measure those metrics? I for one can't think of a useful algorithm which helps to identify understaffed or orphaned areas. Sure, one might take a look at the number of packages compared with open bugs for example - but in the end that still won't give you some useful metrics. If someone has a feeling somewhere helping hands are missing or an area is orphaned - that's the best metrics we can get. - Tobias -- Praxisbuch Nagios http://www.oreilly.de/catalog/pbnagiosger/ https://www.xing.com/profile/Tobias_Scherbaum signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 03/04/10 08:40, Dror Levin wrote: On Sat, Apr 3, 2010 at 16:19, Ben de Groot yng...@gentoo.org wrote: 1 - requirements In order to choose the best possible wiki implementation, we need to know our requirements. So what features do you think are essential or good to have? What syntax would we prefer to use? I myself am a big fan of reStructuredText, which is quite simple, easy to pick up, highly readable, and has a good featureset. Plus, it is also reusable in other contexts (it is for example widely used in documentation of Python libraries). MediaWiki, MoinMoin and Trac have support for rst. Some others: - active upstream (bug fixes, security updates) - free open source software - ACLs - spam prevention measures - attachments (to upload screenshots for example) - feeds There is currently a wiki for gentoo at gentoo-wiki.com, which is running MediaWiki, so it would be easiest to transfer the content if we were to run the same software. Now, this doesn't mean we should be limited by their actions, but it seems to me like the best choice for other reasons as well. Its syntax is probably the most well known, thanks to Wikipedia. Its upstream is active, it apparently scales and performs pretty well, it's GPL, supports translations/localization, feeds, attachments, etc. I'm sure many other alternatives are as qualified, so this is most likely a personal preference issue. As such, lets just agree on something that works and is widespread and go with that and avoid all the bikeshedding. 2 - maintainers === Who is volunteering for maintaining the wiki? We need editors and moderators, people who look out for quality control and take care of spam removal. So let's get together a team. I'm sure if we ask on the forums we'll get some users interested as well. I volunteer. Spam shouldn't be that much of an issue if editing is restricted to registered users, but it is a good idea to have a team of moderators similar to the one that exists for the forums (of course users can take part of it as well as developers). 3 - edit access === Do we keep to the original free for all model, with all the spam that includes, or do we go with registered users only? I think the latter is the smarter option. I also think we will want to mark certain pages official and lock down editing rights. IMO it's best if only registered users can edit (but registering should be easy, no bugs to file or anything, just sign up and use immediately). This will probably prevent most kinds of spam and allow for much better tracking of editing and history, allow for banning, etc. without closing the wiki up too much. Also, from what I could tell, this is how others are managing their wiki as well (Arch and Amarok, for example). Dror Levin I would enjoy working on a wiki as well as the fora, so I'm volunteering as well. --Nathan Zachary
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03-04-2010 09:50, Petteri Räty wrote: I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I disagree. Resolved LATER is useful to some maintainers that want to fix that bug, but don't have time or don't find the issue to be a priority at the moment. By marking it LATER they're acknowledging the bug exists and needs to be taken care of. I would like to avoid things like this: https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 You've chosen a terrible example as in that case the resolution is accurate. The forums team didn't find that issue to be a priority and doesn't have the time to deal with it. As the bug was open for years without any progress, we chose to close it as LATER. If someone else wants to step up and take care of it, great. Not applicable to the bug above but in general our social contract says: We will not hide problems When you mark something as LATER because you don't have the time nor find it a priority, you're not hidding a problem. If someone uses that resolution to hide problems, that person should be warned of the above. Regards, Petteri - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLt13jAAoJEC8ZTXQF1qEPVbkP/2rux+TdVxLUDl1WjKC4IOwT sVLs4slXFYxIsd5TxlaxA9/nkPFVUiUtzmCwNHdYRLIxQpbJk2FHhHzfeuT6h2nF 0n29V9mRobXvMxUAIKNuu8F8VEoKPouKBF64rPoOgqv4KG1bmnAvmS1VzxMMj9Gi RO2Zt9xlb1rDzy1/fTLUCT0LKvuMZvPv5ZxXBfqDZT9fD4bEFH63RfVnOaEGU/X4 7MMju7MhSxpZxpea/jTIXSEnblH/lbjwM4aYunrFvGq/O4i1A45SS2iASqN2xsmj FCVzzigCFD0htI7pvJkCgW560UPX102jHUMxEIlMluoBsT+LvgiAVca9vySfLKF+ CuQEGpLaXFpWyJjHMW9tCKdEFZkSV7oTC1vuCwOXU5beHhHA7AHqR0j1ADTJIQa7 d2GOHkKRrrUSqmwRL4gjOj1C8LHkHdpVKAg8Ni6HTdd2aAQEGb4R+0mCZM8zJ19r zQpCqYI4zpKOhkvYRQf7VtdgmvRbw5KX8qjjRi4DDy8+larFYLc1GcYDpuGp2W56 MfYkZy6EgAdwmKyrFlknxkYXk64FWtsWNSzTMW6Wi/Xu9OiL9ArAbgO8d2DdRL3T p4acejrSxHbGL3wXMsOOOVkUf2rLjA1XTukgk4VK4fEKg0ITa8RIewRZRQtS0WyF odz4rA5x2k2HwLvgA52I =XTLq -END PGP SIGNATURE-
RE: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Hi everyone, Gentoo-Quebec already use MediaWiki and I can say that for the spam prevention measures it can be pretty simple : For a new user, he needs to send an email to a specific adress, alos he needs to have a valid account on the forum just to be sure that he is not a spambot. So basically, only members of the forum can write something on the wiki. For the rest, if you need a moderator or a writer on that project, I can help :P Finally, I recommend that on the Wiki team, the best team should be : experimented users (power users), users,moderators and Gentoo Devs for specific areas. Date: Sat, 3 Apr 2010 10:04:38 -0400 From: guy.fonta...@videotron.qc.ca To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki Hi ! I maintain Gentoo-Québec wiki. I'm not the only one as d2_racing and some other members also do. I maintain CSS, examples and wrote almost 60% of the stuff. If you think I could help, please just let me know. The wiki : http://gentoo-quebec.org/wiki/index.php/Accueil Guy Fontaine _ Hotmail Messenger are available on your phone. Try now. http://go.microsoft.com/?linkid=9724461
Re: [gentoo-dev] spin (spinroot.com) license
On 04/03/2010 04:16 AM, Paweł Hajdan, Jr. wrote: I'd like to add a package for spin to the tree (it's used at several universities, including mine and Caltech). However, it's not straightforward. The basic license is for educational purposes only. Here are my suggestions how to implement that. /usr/portage/licenses/spin-educational with the following content: Copyright (c) 1989-2006 Lucent Technologies, Bell Labs Extensions (c) 2006-2009 NASA/JPL California Institute of Technology All Rights Reserved. For educational purposes only. No guarantee whatsoever is expressed or implied by the distribution of this code. /usr/portage/licenses/spin-commercial with the content pasted from http://www.spinroot.com/spin/spin_license.html And then in the ebuild: LICENSE=|| ( spin-educational spin-commercial ) Are there any license groups these should be added to? They both look like they belong in the EULA group to me. The educational one is an EULA in the sense the the user must agree to use it only for educational purposes. -- Thanks, Zac
Re: [gentoo-dev] Is Gentoo dying?
On Sat, Apr 3, 2010 at 7:59 AM, Tobias Scherbaum dertobi...@gentoo.org wrote:
Am Samstag, den 03.04.2010, 15:40 +0100 schrieb Roy Bamford:
First, we need some metrics - the first step to controlling anything is
to measure it.
So, how do you want to measure those metrics? I for one can't think of a
useful algorithm which helps to identify understaffed or orphaned areas.
Sure, one might take a look at the number of packages compared with open
bugs for example - but in the end that still won't give you some useful
metrics.
When I was a treecleaner I tended to look at a few things; note that
because we enforce very little in the tree these are basically just a
set of heuristics.
- metadata.xml: how many packages are maintainer-{needed,wanted}.
Does not apply to all herds because some herds fix anything in their
herd.
- date of last commit: Gentoo is fast moving and packages that
haven't had commits since 200{4,5,6} are probably old, unmaintained
and may not even compile or run.
- date of last listed maintainer commit versus last commit:
Basically if the maintainer hasn't touched the ebuild in a while but
someone else (herd members?) have, the metadata.xml is probably out of
date.
The above are all pretty easy to do with the data in the tree. Some
other useful ideas might be:
- compare open bugs for the package, when was the last bug for a
package closed (bugs data kinda sucks for this)
- for a given package in a herd, check the version in the tree
against freshmeat or similar to see how far behind it is (I think
someone wrote something for this already, exherbo?)
- check imlate to see if keywording is behind (is the maintainer
filing stablereqs?)
Metrics do not have to be perfect (they never are...) but they may
shine some light on some areas of the tree that need staff.
-A
If someone has a feeling somewhere helping hands are missing or an area
is orphaned - that's the best metrics we can get.
- Tobias
--
Praxisbuch Nagios
http://www.oreilly.de/catalog/pbnagiosger/
https://www.xing.com/profile/Tobias_Scherbaum
Re: [gentoo-dev] Is Gentoo dying?
Alec Warner wrote: The above are all pretty easy to do with the data in the tree. Some other useful ideas might be: - compare open bugs for the package, when was the last bug for a package closed (bugs data kinda sucks for this) An additional search: last touched by assignee between never and now-30 days. I also just discovered that awesome query interface our bugzilla has. Can we publish a data set query where new bugs are plotted against closed bugs (maybe add already open bugs) for each herd? I'll try to come up with a query if no one else is faster with this. If the difference between new and closed bugs in a 30 days time period is over a given threshold (say 15% of the current open bugs), this might be a herd that needs help. Maybe we can come up with more insightful bugzie searches. And maybe something like that exists already and i've failed finding it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On 04/03/2010 06:25 PM, Jorge Manuel B. S. Vicetto wrote: On 03-04-2010 09:50, Petteri Räty wrote: I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I disagree. Resolved LATER is useful to some maintainers that want to fix that bug, but don't have time or don't find the issue to be a priority at the moment. By marking it LATER they're acknowledging the bug exists and needs to be taken care of. What is the benefit with this instead of keeping it open until they find time? I doubt for example bug days take LATER resolved bugs into account or user are likely to search for them when trying to find something to work on. I would like to avoid things like this: https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 You've chosen a terrible example as in that case the resolution is accurate. The forums team didn't find that issue to be a priority and doesn't have the time to deal with it. As the bug was open for years without any progress, we chose to close it as LATER. If someone else wants to step up and take care of it, great. Yeah there's probably better examples out there but that's what sparked me to think about this so I went with it. From a recruiter perspective the need to tie to LDAP is still there so the issue isn't gone. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Portage, kernel sources and setgid
Hello, I am using umask 027 on my Gentoo boxes, and setgid bit set on a few directories crucial to userpriv-enabled merges. This way, I do not have to worry about running e.g. layman through 'sg' or similar tools, as all newly-created files inherit portage group ownership, and newly-created directories inherit the setgid bit. I would like to be able to use similar solution for compiled kernel sources, i.e. through setting the setgid bit on /usr/src. But in fact it is impossible as portage forces setting it's own permissions on all installed files, thus newly-installed kernel sources do not inherit the parent group ownership nor the setgid bit. Now the question is: should such behaviour be considered really correct and necessary? In my opinion, if user sets setuid/setgid on a parent directory, shklee knows what shklee is doing and emerge should not override this system-specific ownership inheritance. -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 03/04/10 14:40, Dror Levin wrote: On Sat, Apr 3, 2010 at 16:19, Ben de Groot yng...@gentoo.org wrote: 2 - maintainers === Who is volunteering for maintaining the wiki? We need editors and moderators, people who look out for quality control and take care of spam removal. So let's get together a team. I'm sure if we ask on the forums we'll get some users interested as well. I volunteer. Spam shouldn't be that much of an issue if editing is restricted to registered users, but it is a good idea to have a team of moderators similar to the one that exists for the forums (of course users can take part of it as well as developers). Most of the spam on gentoo-wiki.com comes from registered accounts. Requiring registration does not stop most wiki spam. Very little of the spam comes in from unregistered editors. On gentoo-wiki.com we currently use a combination of anti-spam tools, which seems to work best. The main 2, from a day-to-day administration view are the url blacklist and manual removal of spam and associated accounts. You could require email authentication first, but I believe this is unlikely to reduce spam - creating a setup that automatically deals with account verification emails is trivial and throwaway accounts are too easy to get hold of. In addition I believe it would reduce the amount of positive contribution more than it reduces spam - I believe people often want to make quick, small corrections / additions and telling them to come back later is going to be the same as telling them go away. I would highly recommend using MediaWiki as, at least from my experience, it's the most prevalent of the wiki setups available. While this may bring some disadvantages (number of spam attempts (tho I'm nottotally convinced you'll get less than any other web form out there), etc), it also brings the advantages of being well developed with a wide variety of plugins, lots of wiki syntax guides / tutorials you can point users to and a wide userbase with existing knowledge of the syntax. AllenJB
Re: [gentoo-dev] are hardened-sources maintained?
On 1 April 2010 15:43, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Of course that would mean getting included in hardened-ker...@gentoo.org, but I guess it's the easiest part. Yes, you can do it yourself: woodpecker ~ $ echo $USER /var/mail/alias/misc/hardened-kernel -- Best Regards Piotr Jaroszyński
Re: [gentoo-dev] Portage, kernel sources and setgid
On 04/03/2010 10:11 AM, Michał Górny wrote: Hello, I am using umask 027 on my Gentoo boxes, and setgid bit set on a few directories crucial to userpriv-enabled merges. This way, I do not have to worry about running e.g. layman through 'sg' or similar tools, as all newly-created files inherit portage group ownership, and newly-created directories inherit the setgid bit. I would like to be able to use similar solution for compiled kernel sources, i.e. through setting the setgid bit on /usr/src. But in fact it is impossible as portage forces setting it's own permissions on all installed files, thus newly-installed kernel sources do not inherit the parent group ownership nor the setgid bit. Now the question is: should such behaviour be considered really correct and necessary? In my opinion, if user sets setuid/setgid on a parent directory, shklee knows what shklee is doing and emerge should not override this system-specific ownership inheritance. Your issue seems somewhat related to this bug: http://bugs.gentoo.org/show_bug.cgi?id=141619 My first inclination is to use configuration file for stuff like this, since it's not really possible to distinguish ad hoc permission modifications done by the user from incorrect permissions that are due to other reasons such as faulty ebuilds. It would probably also be a good idea to record file permissions in /var/db/pkg/*/*/CONTENTS, so that we'd have some way know when permissions differ from those initially set by the ebuild, and a way to detect collisions in directory permissions between 2 different ebuilds that install files in the same directory. -- Thanks, Zac
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On Sat, Apr 3, 2010 at 10:10 AM, Petteri Räty betelge...@gentoo.org wrote: On 04/03/2010 06:25 PM, Jorge Manuel B. S. Vicetto wrote: On 03-04-2010 09:50, Petteri Räty wrote: I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I disagree. Resolved LATER is useful to some maintainers that want to fix that bug, but don't have time or don't find the issue to be a priority at the moment. By marking it LATER they're acknowledging the bug exists and needs to be taken care of. What is the benefit with this instead of keeping it open until they find time? I doubt for example bug days take LATER resolved bugs into account or user are likely to search for them when trying to find something to work on. I would vote for a LATER KEYWORD instead of a resolution. Really what I would want when searching is to know what set of bugs I should be working on short-term versus bugs I'd consider more like 'project-work'. LATER is typically stuff that is: - too big to do now, but may get covered in some kind of sprint or fixit. - blocking on something else (EAPI, upstream revbump, etc.) - too hard to do now, but may be easier in the future (kind of like #2, but possibly unrelated) The point is I'm looking for a set of bugs that are possible to fix now; and currently closing some types of bugs as RESOLVED:LATER does this for me. -A I would like to avoid things like this: https://bugs.gentoo.org/show_bug.cgi?id=113121#c21 You've chosen a terrible example as in that case the resolution is accurate. The forums team didn't find that issue to be a priority and doesn't have the time to deal with it. As the bug was open for years without any progress, we chose to close it as LATER. If someone else wants to step up and take care of it, great. Yeah there's probably better examples out there but that's what sparked me to think about this so I went with it. From a recruiter perspective the need to tie to LDAP is still there so the issue isn't gone. Regards, Petteri
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On 04/03/2010 08:54 PM, Alec Warner wrote: On Sat, Apr 3, 2010 at 10:10 AM, Petteri Räty betelge...@gentoo.org wrote: On 04/03/2010 06:25 PM, Jorge Manuel B. S. Vicetto wrote: On 03-04-2010 09:50, Petteri Räty wrote: I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I disagree. Resolved LATER is useful to some maintainers that want to fix that bug, but don't have time or don't find the issue to be a priority at the moment. By marking it LATER they're acknowledging the bug exists and needs to be taken care of. What is the benefit with this instead of keeping it open until they find time? I doubt for example bug days take LATER resolved bugs into account or user are likely to search for them when trying to find something to work on. I would vote for a LATER KEYWORD instead of a resolution. Really what I would want when searching is to know what set of bugs I should be working on short-term versus bugs I'd consider more like 'project-work'. LATER is typically stuff that is: - too big to do now, but may get covered in some kind of sprint or fixit. - blocking on something else (EAPI, upstream revbump, etc.) - too hard to do now, but may be easier in the future (kind of like #2, but possibly unrelated) For #2 you can use dependencies. I have no problem adding a keyword as it keeps the bugs open. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
Am Samstag, den 03.04.2010, 12:38 +0200 schrieb Maciej Mrozowski: Problem ..is known, let me summarize briefly. Uninstalling packages providing libraries, without checking reverse runtime dependencies of those packages leaves their dependencies unsatisfied (packages with broken executables and/or shared libs). Some package managers try their best not to remove said libraries, yet allowing packages to be removed. Those orphaned libraries cause problems[1] as build systems of some other packages being (re)installed afterwards pick them up and abuse those orphaned libraries. (we don't like orphans abused, we prefer them... gone). Solution Now, I suppose there are some ideas how to make orphaned libraries not go in a way. Basically then need to be available for system, but hidden for emerge. There is opt-out suggestion[2], unfortunately it does not provide any info how exactly it's supposed to be achieved. As far as portage/pkgcore is concerned, maybe - as Brian Harring suggested - sandbox could be used to somehow hide preserved libraries or preserved library directory from ebuild environment (preserved library directory a'ka purgatory - libs could be moved there when considered orphaned). Opt-in suggestion is as follows: 1. Use some library path (read by ld loader from environment) and export it globally to environment pointing it to preserved library directory. 2. During emerge, unset environment variable corresponding to said preserved library directory - orphans are no longer located. Attached patch for glibc (2.11, but should apply to any other glibc around) and uClibc (this one is not tested but should work as well) that makes ld loader aware of LD_GENTOO_PRESERVED_LIBRARY_PATH variable. (LD_LIBRARY_PATH would work as well, but it's being used widely so cannot be safely mangled.. on the second though it can - one could filter out preserved library paths from it during emerge). Thoughts? Don't fix the hack. Remove the preserve libs feature, make the PMs check for rdeps per default before unmerging things. Slot libraries where needed, slot dep operators (EAPI 4) will help. And if that doesn't work out we need a separate var to give the PM a hint when API/ABI breakages happen (such that the PM knows when to re-install the rev deps). -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 03/04/2010 18:40, AllenJB wrote: On 03/04/10 14:40, Dror Levin wrote: On Sat, Apr 3, 2010 at 16:19, Ben de Grootyng...@gentoo.org wrote: 2 - maintainers === Who is volunteering for maintaining the wiki? We need editors and moderators, people who look out for quality control and take care of spam removal. So let's get together a team. I'm sure if we ask on the forums we'll get some users interested as well. I volunteer. Spam shouldn't be that much of an issue if editing is restricted to registered users, but it is a good idea to have a team of moderators similar to the one that exists for the forums (of course users can take part of it as well as developers). Most of the spam on gentoo-wiki.com comes from registered accounts. Requiring registration does not stop most wiki spam. Very little of the spam comes in from unregistered editors. On gentoo-wiki.com we currently use a combination of anti-spam tools, which seems to work best. The main 2, from a day-to-day administration view are the url blacklist and manual removal of spam and associated accounts. You could require email authentication first, but I believe this is unlikely to reduce spam - creating a setup that automatically deals with account verification emails is trivial and throwaway accounts are too easy to get hold of. In addition I believe it would reduce the amount of positive contribution more than it reduces spam - I believe people often want to make quick, small corrections / additions and telling them to come back later is going to be the same as telling them go away. I would highly recommend using MediaWiki as, at least from my experience, it's the most prevalent of the wiki setups available. While this may bring some disadvantages (number of spam attempts (tho I'm nottotally convinced you'll get less than any other web form out there), etc), it also brings the advantages of being well developed with a wide variety of plugins, lots of wiki syntax guides / tutorials you can point users to and a wide userbase with existing knowledge of the syntax. AllenJB Does mediawiki have captcha ability?
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
Am Samstag, den 03.04.2010, 12:50 +0300 schrieb Petteri Räty: I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? I would like to avoid things like this: Yes, please remove it. Keep it simple and stupid. LATER means it's not resolved and is as such not a valid resolution. -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
Hi guys, On Sat, Apr 3, 2010 at 9:10 AM, Ben de Groot yng...@gentoo.org wrote: On 3 April 2010 13:33, Richard Freeman ri...@gentoo.org wrote: I really think that the Gentoo recruitment process needs improvement. Right now it seems like a LOT of effort is required both to become a Gentoo dev and to help somebody become a Gentoo dev. That means we have great people, but not many of them. I agree. So what can we do to improve this process? I myself am not fond of the quizzes, and from what I've seen most recruits find them tedious as well. It can be quite demotivating, maybe because it reminds one too much of highschool or something. I took a long time myself to finish them, and that wouldn't have been necessary, as my mentors ensured me I was ready to become a dev. And I see the same thing happening with some of my own recruits. They can be ready, but just find the quizzes a chore. I understand that quizzes serve a purpose and IMHO, are a good way to face common issues when writing ebuilds. On the other hand, I understand that quizzes are lengthy and could become a blocker in the recruitment process (I have met at least two prospects drop out due to the inability to finish them, being for lack of time to concentrate or because they got bored by the chore.) Maybe if we could find the way to make the knowledge found in quizzes be more exciting to new devs, then we could still have a strong recruitment process without the burden of completing the quizzes. So, what I propose is to transform the quizzes part of the process into a list of tasks the prospect should complete in order to gain the necessary ability to pass. This ability could be measured in points or just by task completed. Then it gets interesting for them and for us. Those tasks could be to tackle problems from the quizzes but in real ebuilds (prepared by us for this, much as when recruiters ask us to clean some ebuild) or could be tasks created by teams to specifically address common issues in their domain if the prospect is trying to join them or shows an interest on helping this specific team. Of course this doesn't address the organizational side of things, so we need to come up with something else for that. This doesn't address them either. But I really don't think this is the main issue that causes the problem :) So I guess these questions could remain in one easy quiz. -- Ben de Groot Gentoo Linux Qt project lead developer If I can be of any assistance in this, I'll gladly help. -- Jesus Rivero (Neurogeek) Gentoo Python Team
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sat, 03 Apr 2010 19:56:53 +0100, George Prowse george.pro...@gmail.com wrote: Does mediawiki have captcha ability? Yes, there are plug-ins provide that functionality. [1] Let's get a general Wiki concept done before talking about spam remedy in detail, though. :) [1] http://www.mediawiki.org/wiki/Manual:Combating_spam#Captcha -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Is Gentoo dying?
On Sat, Apr 3, 2010 at 05:38, Petteri Räty betelge...@gentoo.org wrote: My perception from the outside is also that it's sometimes hard to offer help. So if we now that we are busy then let's try to embrace others doing the work. This is also what I have observed. I think Gentoo needs appear to be much more focused on how to let people contribute, rather than how to filter/monitor contributions. There's too much discussion about how something is bad and why it shouldn't happen in the documentation and mailing list, and too little about what can be done to make sure the contribution, idea, or user(s) get included. One specific example I can give is the developer status itself. Gentoo developers are responsible for everything, including maintenance. This is not a bad thing, if it's part of a greater developer ecosystem. All successful projects I've observed survive on half of the work, at least, being done by volunteers, and the developers are there to simply review the work before it is applied. As far as I can tell, creating an inviting atmosphere, in which the developers listen and react to the community, is essential to the continued survival of Gentoo. Yea, this one of those long-term things that sounds awesome in theory but is hard to do right. However, I think the sooner ideas like these are discussed and possibly implemented, the sooner we don't have threads like these in the mailing list. I am encouraged that Gentoo developers are considering how to regroup themselves. -- Jacob For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened. Are you ready?
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sat, 3 Apr 2010 15:19:20 +0200, Ben de Groot yng...@gentoo.org wrote: Okay, so it seems a lot of people do want a wiki. So let's see what we can do to make that happen. I created a Wiki page (oh, the irony) to track the results of this thread in the Gentoo eV wiki: http://gentoo-ev.org/wiki/Official_Gentoo_wiki Feel free to edit the page or email me changes. Alex -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Re: List of User projects
On Sun, Mar 28, 2010 at 10:27, Duncan 1i5t5.dun...@cox.net wrote: What other distributions (*BSD, Linux, or...) do you know that use openrc? IOW, I know it was designed to be distribution independent, but I don't know of anyone else using it (well, other than Gentoo derivatives), and Gentoo certainly influenced it. Last I checked, Ubuntu is going to adopt it. How's that for a compliment? :) http://brainstorm.ubuntu.com/idea/18452/ -- Jacob For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened. Are you ready?
Re: [gentoo-dev] Re: List of User projects
On Sat, Apr 3, 2010 at 15:30, Jacob Godserv jacobgods...@gmail.com wrote: Last I checked, Ubuntu is going to adopt it. How's that for a compliment? :) http://brainstorm.ubuntu.com/idea/18452/ Sorry for the extra e-mail, but I should clarify: Ubuntu is seriously considering adopting it. -- Jacob For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened. Are you ready?
Re: [gentoo-dev] Re: List of User projects
On Sat, 3 Apr 2010 15:31:20 -0400 Jacob Godserv jacobgods...@gmail.com wrote: On Sat, Apr 3, 2010 at 15:30, Jacob Godserv jacobgods...@gmail.com wrote: Last I checked, Ubuntu is going to adopt it. How's that for a compliment? :) http://brainstorm.ubuntu.com/idea/18452/ Sorry for the extra e-mail, but I should clarify: Ubuntu is seriously considering adopting it. No offence but '-15' doesn't sounds as serious as '344' for upstart. -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Saturday 03 of April 2010 14:16:14 Fabian Groffen wrote: Shouldn't we fix that buildsystem then? Do you have an example of a package/buildsystem that does that? We already do, the thing is that maybe we don't have to. https://bugs.gentoo.org/show_bug.cgi?id=240323 From top of my head: python having issues with sys-libs/db as well as some packages with readline. It would indeed. Now when I think about it, moving stuff to preserved library dir could be just done - provided it's possible - along with fixing/setting DT_RPATH's in reverse runtime dependencies. This way no system-wide LIBRARY_PATH's would be necessary. Is it possible? Mike? No, unless you somehow make sure you reserve space for this, by e.g. setting a bogus rpath entry at buildtime. If you want to go that route, you probably want to look at the Prefix' binutils-config wrapper that already calls the linker with added rpath arguments. Afterwards you can use chrpath to set it to the correct location. Will get messy with the vdb though, but if Portage's doing it, it can probably be dealt with. Sounds messy indeed, what about hardened/SELinux/AppArmor/whatever - do they allow such DT_RPATH operations? It should be probably also restricted for binary-only packages. On Saturday 03 of April 2010 20:51:43 Tiziano Müller wrote: Don't fix the hack. Remove the preserve libs feature, make the PMs check for rdeps per default before unmerging things. This will only prevent creating orphans of uninstalled libraries, what about upgraded ones when SOVERSION has been bumped (the most common case)? Besides I can already imagine PMS-related discussion regarding make the PMs check for rdeps per default before unmerging things - thx but no thx. Slot libraries where needed, slot dep operators (EAPI 4) will help. Again, you suggest to SLOT every library that happened to bump SOVERSION. It's unrealistic. Besides library should be slotted when it's API changes, for source based distributions it's not needed for ABI changes - let's not confuse those two. Also excessive slotting increases probability of breaking library discovery mechanisms in various build systems (not everyone uses pkg-config). And if that doesn't work out we need a separate var to give the PM a hint when API/ABI breakages happen (such that the PM knows when to re-install the rev deps). It needs PMS amended and thus GLEP. Please submit a GLEP item for this if you see it fit. Anyway, as explained in OT, it's not a problem of package manager dependencies system but issue with broken/not smart build systems - no dependency tree magic will solve this issue. -- regards MM
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 04/03/10 16:05, Petteri Räty wrote: http://www.gentoo.org/proj/en/devrel/staffing-needs/ I don't know if developers know that this page is autogenerated from individual project pages these days so it's easy for any developer to get stuff there. Has anyone every tried to read that page? It's such a pain to that I doubt it. Sebastian
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 04/03/10 21:00, Jesus Rivero (Neurogeek) wrote: Maybe if we could find the way to make the knowledge found in quizzes be more exciting to new devs, then we could still have a strong recruitment process without the burden of completing the quizzes. So, what I propose is to transform the quizzes part of the process into a list of tasks the prospect should complete in order to gain the necessary ability to pass. This ability could be measured in points or just by task completed. Nice idea! This doesn't address them either. But I really don't think this is the main issue that causes the problem :) So I guess these questions could remain in one easy quiz. While you mention the non-technical part: I imagine a gain out of moving that part to the very end of recruiting: to when people know they almost made it. Especially putting up these questions first, turns some people away too: The problem is they get the wrong impression that being will be about these boring things later on, but it isn't. Betelgeuse, what do you think? Sebastian
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
Le samedi 03 avril 2010 à 12:50 +0300, Petteri Räty a écrit : I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? You are trying to remove a valid status for a case that has been badly managed ??? Speaking for gnome herd, afaik, all bugs marked LATER are for the simple reason they will be done later and no other status would be fine expect REJECTED maybe, but we don't want to say that to the face of the reported like this do we ? -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
2010/4/3 Gilles Dartiguelongue e...@gentoo.org: Le samedi 03 avril 2010 à 12:50 +0300, Petteri Räty a écrit : I don't think later is valid resolution. If there's a valid bug it just means it's never looked at again. If the bug is not valid then a different resolution should be used. So what do you think about disabling later? You are trying to remove a valid status for a case that has been badly managed ??? Speaking for gnome herd, afaik, all bugs marked LATER are for the simple reason they will be done later and no other status would be fine expect REJECTED maybe, but we don't want to say that to the face of the reported like this do we ? Thats why I think a bugzilla LATER keyword is just as effective; but people doing bugzie searches would no longer exclude these types of bugs on accident. -A -- Gilles Dartiguelongue e...@gentoo.org Gentoo
[gentoo-dev] [Gentoo Pheonix] Heartbeat team force
I'm calling for participation in a new team working on things around reports, bug analysis, heartbeat tracking in Gentoo: Goals = - help track the heartbeat/breath of Gentoo (bugs fixed per day, bug distribution per herd, ..) - point to problems we may be overlooking in Gentoo (letting numbers speak to us and listening to them) - help to prioritize when distributing available resources (specific calls for help, people switching teams, ..) Data we will be working with - The Bug database (XML from Bugzilla, ..) - Package tree history (VCS logs, ..) - User setup details (gentoo-smolt, ..) - .. Concrete tasks == - bugday.g.o re-write (work in progress) - work on association between bugs and packages (for all bugs, not just bugday ones) - get real numbers on how much active manpower we have People == These poeple are in de facto: - deathwing00 - sping - you here? If this is stuff which - you have time for - you are good at please join us! Sebastian
Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force
On Sat, Apr 3, 2010 at 5:54 PM, Sebastian Pipping sp...@gentoo.org wrote: I'm calling for participation in a new team working on things around reports, bug analysis, heartbeat tracking in Gentoo: Goals = - help track the heartbeat/breath of Gentoo (bugs fixed per day, bug distribution per herd, ..) - point to problems we may be overlooking in Gentoo (letting numbers speak to us and listening to them) - help to prioritize when distributing available resources (specific calls for help, people switching teams, ..) Data we will be working with - The Bug database (XML from Bugzilla, ..) - Package tree history (VCS logs, ..) - User setup details (gentoo-smolt, ..) - .. Concrete tasks == - bugday.g.o re-write (work in progress) - work on association between bugs and packages (for all bugs, not just bugday ones) - get real numbers on how much active manpower we have People == These poeple are in de facto: - deathwing00 - sping - you here? Sebastian, count me in. I believe this sort of stuff, or small parts of what you are mentioning, was done in the newsletter. I believe this is something real nice we should put somewhere public. If this is stuff which - you have time for - you are good at please join us! Sebastian Best regards, -- Jesus Rivero (Neurogeek) Gentoo Python Team
Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force
On Sat, Apr 3, 2010 at 3:24 PM, Sebastian Pipping sp...@gentoo.org wrote: I'm calling for participation in a new team working on things around reports, bug analysis, heartbeat tracking in Gentoo: I will help with scripting; but probably not much else. -A Goals = - help track the heartbeat/breath of Gentoo (bugs fixed per day, bug distribution per herd, ..) - point to problems we may be overlooking in Gentoo (letting numbers speak to us and listening to them) - help to prioritize when distributing available resources (specific calls for help, people switching teams, ..) Data we will be working with - The Bug database (XML from Bugzilla, ..) - Package tree history (VCS logs, ..) - User setup details (gentoo-smolt, ..) - .. Concrete tasks == - bugday.g.o re-write (work in progress) - work on association between bugs and packages (for all bugs, not just bugday ones) - get real numbers on how much active manpower we have People == These poeple are in de facto: - deathwing00 - sping - you here? If this is stuff which - you have time for - you are good at please join us! Sebastian
Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force
On 04/04/10 00:30, Jesus Rivero (Neurogeek) wrote: Sebastian, count me in. Cool! I believe this sort of stuff, or small parts of what you are mentioning, was done in the newsletter. I believe this is something real nice we should put somewhere public. Can you elaborate on that? I'm not sure what what you refer to. Sebastian
Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force
On 04/04/10 00:42, Alec Warner wrote: I will help with scripting; but probably not much else. Just right, there will be lots of scripting :-) The current script dumping groud is hosted here: http://git.goodpoint.de/?p=gentoo-bug-heartbeat.git;a=summary Sebastian
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/03/10 16:46, Ben de Groot wrote: I propose to use MediaWiki. As I said in my other post, MediaWiki and MoinMoin should, in my opinion, be on our shortlist to consider. My vote on MediaWiki, too. (I do like DokuWiki better for personal things but mediaWiki seems the best choice for a project this large.) Btw was it Fedora having moved from MoinMoin to MediaWiki? I remember something like that, could be erring though. Here's another idea: The German Wikipedia uses a concept called sighted revisions. If you visit an article without logging in you will see the latest sighted revision, as an identified user you can also view the latest revision. That's an interesting idea, which we should consider. I'm not sure if that a thing to go for. Drawbacks: - More work (whereas we could use more manpower already) - New bottlenecks Couldn't we just make two big namespaces 'devs'-- Developers only 'registered' -- Full edit access to any registered user in the same wiki and have pages be in either namespace, reflecting the namespace in the page name or path somehow? I expect that to be - easy to implement - providing a good mix of openness and quality control GuideXML documents are often experienced as an unnecessary barrier. I think you should clearly state again that this is not gonna replace GuideXML, just migrate a few use cases where a wiki fits better. This is what you aim for, right? Sebastian
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/03/10 16:36, Ben de Groot wrote: This also raises the question of license. Our current documentation mostly uses the CC-BY-SA license, while the unoffical wiki adds a non-commercial restriction. By choosing one license over the other we will make copy-pasting content from the source that has the other license, as far as I can see, illegal. I would say that interchange possibilities with our existing official documentation has priority. Good point. I agree that a restriction against commercial usage does not work for us. Sebastian
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Ben, good to see you driving this process! Thanks! Sebastian
Re: [gentoo-dev] Is Gentoo dying?
On 04/03/10 18:03, Alec Warner wrote:
- date of last commit: Gentoo is fast moving and packages that
haven't had commits since 200{4,5,6} are probably old, unmaintained
and may not even compile or run.
- date of last listed maintainer commit versus last commit:
Basically if the maintainer hasn't touched the ebuild in a while but
someone else (herd members?) have, the metadata.xml is probably out of
date.
Have the result of that analysis collected somewhere?
The above are all pretty easy to do with the data in the tree. Some
other useful ideas might be:
- compare open bugs for the package, when was the last bug for a
package closed (bugs data kinda sucks for this)
Right, but we can get that working. I have a regex to get package
names from bug titles around that works well. All we need to do is fix
all bug titles ever to contain package names: Could take a whole bugday
or two :-)
- for a given package in a herd, check the version in the tree
against freshmeat or similar to see how far behind it is (I think
someone wrote something for this already, exherbo?)
That's a larger project. GSOC ideas should contain such thing.
- check imlate to see if keywording is behind (is the maintainer
filing stablereqs?)
While you mention that: it's the first time I hear a maintainer should
do that. if so can you raise awareness of it and explain the what and
why in another thread on gentoo-dev?
Sebastian
RE: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Date: Sun, 4 Apr 2010 01:37:03 +0200 From: sp...@gentoo.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki On 04/03/10 16:46, Ben de Groot wrote: I propose to use MediaWiki. As I said in my other post, MediaWiki and MoinMoin should, in my opinion, be on our shortlist to consider. My vote on MediaWiki, too. (I do like DokuWiki better for personal things but mediaWiki seems the best choice for a project this large.) Btw was it Fedora having moved from MoinMoin to MediaWiki? I remember something like that, could be erring though. Here's another idea: The German Wikipedia uses a concept called sighted revisions. If you visit an article without logging in you will see the latest sighted revision, as an identified user you can also view the latest revision. That's an interesting idea, which we should consider. I'm not sure if that a thing to go for. Drawbacks: - More work (whereas we could use more manpower already) - New bottlenecks Couldn't we just make two big namespaces 'devs'-- Developers only 'registered' -- Full edit access to any registered user in the same wiki and have pages be in either namespace, reflecting the namespace in the page name or path somehow? I expect that to be - easy to implement - providing a good mix of openness and quality control GuideXML documents are often experienced as an unnecessary barrier. I think you should clearly state again that this is not gonna replace GuideXML, just migrate a few use cases where a wiki fits better. This is what you aim for, right? Sebastian I hope that you will not migrate the GuideXML inside the wiki, because it's so simple to write documentations inside a wiki and right now the unofficial Gentoo Wiki is clean and simple. If you want to have registered users and contributors, then you need to use a standard syntaxe wiki. Sylvain aka d2_racing _ Got a phone? Get Hotmail Messenger for mobile! http://go.microsoft.com/?linkid=9724464
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/10 02:11, Sylvain Alain wrote: I hope that you will not migrate the GuideXML inside the wiki, because it's so simple to write documentations inside a wiki and right now the unofficial Gentoo Wiki is clean and simple. If you want to have registered users and contributors, then you need to use a standard syntaxe wiki. I didn't plan to, no. On a side not please only quote parts of mails that you actually refer to. It means less scrolling and better context for everybody. Sebastian
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 4 April 2010 01:37, Sebastian Pipping sp...@gentoo.org wrote: Btw was it Fedora having moved from MoinMoin to MediaWiki? I remember something like that, could be erring though. You are right. Here are some relevant links a quick Google search turned up for me: https://fedorahosted.org/fedora-infrastructure/ticket/31 http://fedoraproject.org/wiki/Infrastructure/WikiRequirements https://www.redhat.com/archives/fedora-infrastructure-list/2008-February/msg00085.html It looks like their main concerns were performance, both in terms of scalability and search (the default internal MoinMoin search engine is notoriously slow). Makes you wonder how Ubuntu manage to use MoinMoin apparently succesfully. The conclusion (in my eyes) is that MediaWiki is likely to be the best choice and easiest to set up for our purposes. Unless someone comes with another proposal and good arguments to go with something else, I'd say we should stick to MediaWiki. Here's another idea: The German Wikipedia uses a concept called sighted revisions. If you visit an article without logging in you will see the latest sighted revision, as an identified user you can also view the latest revision. That's an interesting idea, which we should consider. I'm not sure if that a thing to go for. Drawbacks: - More work (whereas we could use more manpower already) - New bottlenecks Couldn't we just make two big namespaces 'devs' -- Developers only 'registered' -- Full edit access to any registered user in the same wiki and have pages be in either namespace, reflecting the namespace in the page name or path somehow? I expect that to be - easy to implement - providing a good mix of openness and quality control Actually this came up in earlier discussions as well, and there was an in my opinion valid concern about the status and quality of user generated documentation, especially if we open it to the wider public as we are proposing here. I think it would be a good thing to give certain revisions of a certain page an offical stamp of approval. It would probably be educational to see how other distros handle that. Does anyone want to volunteer to find that out? GuideXML documents are often experienced as an unnecessary barrier. I think you should clearly state again that this is not gonna replace GuideXML, just migrate a few use cases where a wiki fits better. This is what you aim for, right? A wiki can fulfill several purposes for us: 1. Easy collaboration among devs, for brainstorming, developing new documentation, assembling upcoming meeting agendas, and so on [for which there currently is not really any obvious place] 2. A place for users to collaborate on and contribute to documentation [which is currently covered by the unofficial wiki] 3. A place to host and maintain our existing documentation [which is currently in GuideXML] For me the most important and immediate need is number 1. This is the need that came up several times recently, and the push for me to try to make this happen. I am not pushing for our existing documentation to be migrated into a wiki at this point. But I think that once the place is there, and it functions well, it would be the obvious next step to do so. As I said before, the barrier to contributing and maintaining documentation is much higher in the case of GuideXML, so it doesn't really make sense to keep that around when we have a better solution. I know there are people who do not agree with me on this last point, which is why I see that as a later and separate goal. We can cross that bridge when we come to it. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] Is Gentoo dying?
On Sat, 03 Apr 2010 11:16:32 +0200 Tobias Scherbaum dertobi...@gentoo.org wrote: - Our formerly outstanding documentation still is somewhat maintained, but that's it. I haven't seen any new additions (both to our docs, but also to our docs-team) for years. People are constantly asking for a documentation wiki, but ... Thanks for sh**ting on my efforts. There are lots of visible changes, and I make a point of getting the word out when a new guide turns up in /doc/. I blog about the new docs I add, and I spend awhile working with contributors to make sure we get good stuff out there and that it's constantly updated -- the Openbox guide Nate Zachary wrote comes to mind. I'm also always working with developers who are writing docs in their spare time, coaching 'em through the process, assisting with GuideXML, taking patches, *and* creating patches and updates for devs who are posting documents in /proj/ and in their personal devspace. But I guess that doesn't mean anything to you. Oh yes, and I spend hours each week constantly updating docs based on the inflow of bugs, forum reports, and I constantly re-read each one and improve stuff where I can on-the-fly. Not everything has a bug tracker, but the end result is still a visible difference in the stuff you see on the website. - Website redesign - we had a contest some years ago, got a winner, someone started to adapt the design and somewhat that project fall asleep. We've added quite a bit, with the automated feeds and whatnot. And the sidebar stuff. And the revamping of our releases page, and lots of other areas. I've added lots of stuff; I guess you just haven't noticed. - Speaking of our website, PR ... guess there's nothing more to add. Thanks for sh**ting on my efforts here, too. Take SCALE last month. I guess all the work I did to organize SCALE and go out and make a difference with our (potential) users by talking with them doesn't mean anything. All the word-of-mouth I've done with folks before and after SCALE, even my coworkers must not count for much. * * * I would have expected such this kind of negative, abrasive email from a user, but to see such a sensationalist letter coming from a developer is disappointing, to say the least. I expect better from you. Because whether you realize it or not, your email can only come across as denigrating my efforts, and everyone else who puts in hard work on (actually visible!) changes. Your email was inflammatory and offensive, but not in the way that motivates me to do more or do anything different. It came across as extremely demotivational. signature.asc Description: PGP signature
Re: [gentoo-dev] Is Gentoo dying?
On Sat, Apr 3, 2010 at 6:48 PM, Joshua Saddler nightmo...@gentoo.org wrote: On Sat, 03 Apr 2010 11:16:32 +0200 Tobias Scherbaum dertobi...@gentoo.org wrote: - Our formerly outstanding documentation still is somewhat maintained, but that's it. I haven't seen any new additions (both to our docs, but also to our docs-team) for years. People are constantly asking for a documentation wiki, but ... Thanks for sh**ting on my efforts. There are lots of visible changes, and I make a point of getting the word out when a new guide turns up in /doc/. I blog about the new docs I add, and I spend awhile working with contributors to make sure we get good stuff out there and that it's constantly updated -- the Openbox guide Nate Zachary wrote comes to mind. I'm also always working with developers who are writing docs in their spare time, coaching 'em through the process, assisting with GuideXML, taking patches, *and* creating patches and updates for devs who are posting documents in /proj/ and in their personal devspace. But I guess that doesn't mean anything to you. Oh yes, and I spend hours each week constantly updating docs based on the inflow of bugs, forum reports, and I constantly re-read each one and improve stuff where I can on-the-fly. Not everything has a bug tracker, but the end result is still a visible difference in the stuff you see on the website. You need to take comments less personally. If there is a constant stream of updates then point him at your cia comment log or similar; no need to pick a fight about it. Certainly when compared to our documentation of old I think the rate of new documents and document updates is likely less now than it was then. Perhaps what Tobias is trying to convey is that he wants more people to contribute and write documents. - Website redesign - we had a contest some years ago, got a winner, someone started to adapt the design and somewhat that project fall asleep. We've added quite a bit, with the automated feeds and whatnot. And the sidebar stuff. And the revamping of our releases page, and lots of other areas. I've added lots of stuff; I guess you just haven't noticed. Lots of content sure; not so much on the design side. I personally like our website and I think the design is fine (no need to put too much effort into it IMHO.) but if other folks want to spend time on it I'm not going to say no. I still think something like taking what we have and doing the redesign on non-gentoo stuff and then being like 'yo dawg I heard you like websites so i put a website in your website so you can browse while you browse' or similar is the way to iterate. - Speaking of our website, PR ... guess there's nothing more to add. Thanks for sh**ting on my efforts here, too. Take SCALE last month. I guess all the work I did to organize SCALE and go out and make a difference with our (potential) users by talking with them doesn't mean anything. All the word-of-mouth I've done with folks before and after SCALE, even my coworkers must not count for much. * * * I would have expected such this kind of negative, abrasive email from a user, but to see such a sensationalist letter coming from a developer is disappointing, to say the least. I expect better from you. Because whether you realize it or not, your email can only come across as denigrating my efforts, and everyone else who puts in hard work on (actually visible!) changes. Your email was inflammatory and offensive, but not in the way that motivates me to do more or do anything different. It came across as extremely demotivational. Well it certainly hi-lights one area; that we often fail at communicating what we are doing. The pr team has some great people on it who do great stuff (not including me; I tend to do as little as possible.) Maybe Tobias is blissfully unaware of the efforts of the team. Maybe he thinks the team can do better. I don't see him saying 'well the pr team sucks balls!' I see him saying 'well the pr team is very quiet.' I don't think that is too far from the truth; although certainly pr@ is active it doesn't look like it from anyone not on that alias (SCALE aside.) -A
Re: [gentoo-dev] Is Gentoo dying?
Alec Warner wrote: On Sat, Apr 3, 2010 at 6:48 PM, Joshua Saddlernightmo...@gentoo.org wrote: On Sat, 03 Apr 2010 11:16:32 +0200 Tobias Scherbaumdertobi...@gentoo.org wrote: - Our formerly outstanding documentation still is somewhat maintained, but that's it. I haven't seen any new additions (both to our docs, but also to our docs-team) for years. People are constantly asking for a documentation wiki, but ... Thanks for sh**ting on my efforts. There are lots of visible changes, and I make a point of getting the word out when a new guide turns up in /doc/. I blog about the new docs I add, and I spend awhile working with contributors to make sure we get good stuff out there and that it's constantly updated -- the Openbox guide Nate Zachary wrote comes to mind. I'm also always working with developers who are writing docs in their spare time, coaching 'em through the process, assisting with GuideXML, taking patches, *and* creating patches and updates for devs who are posting documents in /proj/ and in their personal devspace. But I guess that doesn't mean anything to you. Oh yes, and I spend hours each week constantly updating docs based on the inflow of bugs, forum reports, and I constantly re-read each one and improve stuff where I can on-the-fly. Not everything has a bug tracker, but the end result is still a visible difference in the stuff you see on the website. You need to take comments less personally. If there is a constant stream of updates then point him at your cia comment log or similar; no need to pick a fight about it. Certainly when compared to our documentation of old I think the rate of new documents and document updates is likely less now than it was then. Perhaps what Tobias is trying to convey is that he wants more people to contribute and write documents. - Website redesign - we had a contest some years ago, got a winner, someone started to adapt the design and somewhat that project fall asleep. We've added quite a bit, with the automated feeds and whatnot. And the sidebar stuff. And the revamping of our releases page, and lots of other areas. I've added lots of stuff; I guess you just haven't noticed. Lots of content sure; not so much on the design side. I personally like our website and I think the design is fine (no need to put too much effort into it IMHO.) but if other folks want to spend time on it I'm not going to say no. I still think something like taking what we have and doing the redesign on non-gentoo stuff and then being like 'yo dawg I heard you like websites so i put a website in your website so you can browse while you browse' or similar is the way to iterate. - Speaking of our website, PR ... guess there's nothing more to add. Thanks for sh**ting on my efforts here, too. Take SCALE last month. I guess all the work I did to organize SCALE and go out and make a difference with our (potential) users by talking with them doesn't mean anything. All the word-of-mouth I've done with folks before and after SCALE, even my coworkers must not count for much. * * * I would have expected such this kind of negative, abrasive email from a user, but to see such a sensationalist letter coming from a developer is disappointing, to say the least. I expect better from you. Because whether you realize it or not, your email can only come across as denigrating my efforts, and everyone else who puts in hard work on (actually visible!) changes. Your email was inflammatory and offensive, but not in the way that motivates me to do more or do anything different. It came across as extremely demotivational. Well it certainly hi-lights one area; that we often fail at communicating what we are doing. The pr team has some great people on it who do great stuff (not including me; I tend to do as little as possible.) Maybe Tobias is blissfully unaware of the efforts of the team. Maybe he thinks the team can do better. I don't see him saying 'well the pr team sucks balls!' I see him saying 'well the pr team is very quiet.' I don't think that is too far from the truth; although certainly pr@ is active it doesn't look like it from anyone not on that alias (SCALE aside.) -A As a user, I see both sides of this. I rarely go to the actual Gentoo site and mostly read the home page when I do. I may go to a link once in a while that is posted on the mailing list but that is about it. I think what I see from the OP is that he feels there needs to be more people involved in several areas. I don't know you Joshua but if you are doing a lot of the docs by yourself or with just a few helpers, I think you need more help. The pages I do see are really good and I read other people using other distros commend Gentoo on its documentation. It just that maybe you need more help so that even more things can be done. Look at it this way, what would happen if you had twice the help
