Re: [gentoo-dev] Gentoo Council 14/7 introductory meeting
Hi, Am Dienstag, den 13.07.2010, 13:06 -0400 schrieb Richard Freeman: I've seen this at work quite a bit. I've also seen an elegant solution that works moderately well. The minutes of the meeting are taken in realtime during the meeting by whoever will take it, and this is shared with the participants in realtime. This way errors in the minutes are instantly corrected. When the meeting is done you just save and publish the minutes and you are done. Realtime collaboration could involve any number of mechanisms. I don't know if google docs supports it, but I imagine Wave would. There might be other mechanisms as well. Webex/GotoMeeting/etc are usually the methods employed in the business world. There might be an FOSS equivalent. Take a look at app-editors/gobby :) - 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
[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- xmerlin, yoswink, chtekk, omp, tantive, mueli, bluebird, hncaldwell, caleb
Am Mittwoch, den 02.06.2010, 09:18 +0200 schrieb Torsten Veller: net-analyzer/nagios-check_logfiles net-analyzer/nagircbot net-analyzer/pnp4nagios I'll take this packages. - 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
Am Freitag, den 04.06.2010, 00:49 +0200 schrieb Ben de Groot: From what I understand it is still being worked on, but it moves forward very slowly. Maybe someone from the wiki project could add some more up to date info? Initially I was one of those who offered to help with the wiki project and I'm still listed as a member. Accidentally I noticed an initial project meeting which was announced via planet.g.o - but I wasn't able to attend that meeting, as i noticed it just a day or two before. From then on ... I heard just nothing wrt the Wiki project. Sad to say, but that's yet another Gentoo communications fail. - Tobias signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Is Gentoo dying?
Joshua Saddler wrote lots of: Thanks for sh**ting on my efforts. See, this is not about your personal efforts. I really do appreciate the work and time you invest in improving both the docs and PR. But otoh try to compare what the docs-team and PR did say 5 years ago and what they're doing today (at least what becomes visible for people outside of these projects). 5 years ago we had constantly new docs added, we still had our Gentoo Weekly Newsletter - both just some *examples*. Nothing against you personal efforts, but both (important!) areas could be improved and be made more active again. - Tobias
[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?
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] [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] 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] Election for the Gentoo Council empty seat
Am Dienstag, den 15.12.2009, 23:36 -0100 schrieb Jorge Manuel B. S. Vicetto: nomination: December 17th to 30th I'd like to nominate dev-zero. - Tobias -- Praxisbuch Nagios http://www.oreilly.de/catalog/pbnagiosger/ https://www.xing.com/profile/Tobias_Scherbaum signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
Ned Ludd wrote: The devs have a voice one time of the year: when it comes time to vote. But what about the rest of the year? What happens when the person you voted for sucks? You are mostly powerless to do anything other than be really vocal in what seems like a never ending battle. That needs to change. I'm not quite sure how. But I'd like to see the dev body have a year-round voice in the council. Either via quick votes year-round on topics or simply by having discussion in the channel. Devs should have a right to voice their concerns to the council and engage in interactive conversations without being labeled troll. I'm not sure about that, but we can easily give it a try. What I'd like to see for sure is a formal rule on who can decide to modify or change parts of glep 39. As it's the council's constitution somehow, we have two options from my pov (besides that a former council did decide the council itself can change it's rules): - a large majority (at least 5 out of 7) of council members needs to ack the change - changes to glep 39 require a vote with all developers participating and a large majority (2/3 or 3/4) needs to ack the suggested change Also I'd like to require commit messages to gleps (and especially glep 39) being useful and denote based on which decision by whom that change got made. For example the following commit message I'd consider quite useless (at least two or three years ago): Add the one person one vote clause to GLEP 39 as agreed. [1] Who did agree? Where is that noted down? ... and so on. An EAPI review committee could work well also. As long as we could get non bias people in there. I was thinking about that for quite some time and as long as we get some non-biased people in there we should try that as well. The council should be more about community vs technical issues only. We have lots of top level projects within Gentoo which have simply given up on the council as being an outlet to accomplish anything useful. It should be our job to look at the projects in Gentoo. Look at the ones that have a healthy community and encourage and promote them in ways. ack For example prefix comes to mind. It was a project I did not like at first. I'm not even a user. And there are things I surely don't like about it as is. But there is community support and it's the icing on the cake for some. So I'll back the fsck up and give credit where it's due. This is a perfectly good example of a project/fork that needs to come back home. Perhaps it's time to cherry pick some more stuff/people out of Sunrise? prefix is a really good example, yeah. Nearly noone knows it, but it's really cool to have for example a virtualized windows machine running on a linux host. The windows box then runs prefix in interix. Not that it's really useful at all (hey, it's slow as hell) - but it's very interesting that such things are possible and it's definitively an eyecatcher on expos. prefix is one of Gentoo's most underrated projects. As for Sunrise I do think that's what we already do - but: getting users more actively involved in Sunrise makes them happy, plus it's easier for us to recruit new developers. Therefore: push Sunrise! I very much disliked how the Sunrise project has been started some years ago, but in the end we do need to integrate it a tad better to make it even more useful for both users and developers. desultory points out any two council members can decide to approve anything, and that decision is considered to be equivalent to a full council vote until the next meeting. I vaguely recall that rule. I'm not sure about you, but I think that is a little to much power to put in the hands of a few. Any dev mind if we dump that power? It's quite much power in quite a few hands, but in the end that's some kind of last resort rule. All council members should be smart enough (and i do consider all of us being smart enough) to know when that last resort becomes active. Therefore I think it doesn't hurt to have such a rule in place. Meetings will likely go back to one time per month and be +m with +v be handed out per request with open chat pre/post meetings. The reason for this is to keep the meetings on-track. I won't engage in endless discussions. Facts can be presented. They will be reviewed on merit, technical and social. The reason the meetings should go back to monthly is to allow those who are council members in Gentoo to accomplish things other than the council only. We all have personal lives and we all have our respective roles we play outside of the council. Another note on meetings. The time they are held currently don't fit well with my work schedule. I'm all for going back to monthly meetings and make them a tad more organized. As I summarized in the last few minutes of our last council meeting - we do have rules in place to keep our meetings organized, we just need to follow them. As for meeting times we can (that was
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
Alec Warner wrote: What I'd like to see for sure is a formal rule on who can decide to modify or change parts of glep 39. As it's the council's constitution somehow, we have two options from my pov (besides that a former council did decide the council itself can change it's rules): - a large majority (at least 5 out of 7) of council members needs to ack the change - changes to glep 39 require a vote with all developers participating and a large majority (2/3 or 3/4) needs to ack the suggested change Just FYI, Gentoo is lucky if 1/2 of the devs vote; so I assume here you mean large majority of the people who actually voted. Uhrm, yeah ... of course. - Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Monthly Gentoo Council Reminder for July
Mike Frysinger wrote: here's an item that should be relatively quick to address: fix the typo in GLEP 39 where this line is missing (it's been in the council homepage forever): Only Gentoo developers may be nominated I'd like to add that requirement for proxies as well. Varied interpretations of common sense seems to make that necessary. - Tobias
Re: [gentoo-dev] 2009 Council Elections
Denis Dupeyron wrote: Thanks for the reminder, Doug. Make sure to also check everybody's manifesto here: http://www.gentoo.org/proj/en/elections/council-200906-nominees.xml Just for the record - i did add my manifesto to the elections page myself as that somehow got missed. - Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for June 25
Petteri Räty wrote: I think we agreed that we would send comments about the agenda before the meeting. The agenda presented seems fine to me. I don't see a need for doing any major votes in the last meeting. ACKing the agenda, too. I didn't started to get the deployment part of the eapi-development and deployment discussion alive, mainly because Ciaranm has made a true point (we do need testing, of course) and i'm not really sure how to find a balanced way of clean eapi-deployment while also having extensive testing in-tree. Plus it seems i'm the only one interested in that discussion. - Tobias -- Gentoo Linux - Die Metadistribution http://www.mitp.de/5941 http://www.metadistribution.eu https://www.xing.com/profile/Tobias_Scherbaum signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
Tiziano Müller wrote: The people I'd like to nominate: - dertobi123 ... for his solid comments, experience, common sense, reliability And I accept the nomination. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for June 11
Tiziano Müller wrote: EAPI 3: Short discussion of the progress zmedico will provide an update on the progress of the implementation. Short discussion of problems and implementation decisions if needed. Guess that's a rather short topic. Nothing to discuss for us. Default ACCEPT_LICENSE -- Goal: A possible default value for ACCEPT_LICENSE has been proposed. Decide whether that's ok. What happens to the X11 license files (one for each app)? The proposed default looks good to me. Besides that the X11 license stuff needs to get sorted out finally (if it hasn't been already - MIT?). Bash-4 in EAPI-3 Goal: A request has been made to allow bash-4.0 features in EAPI-3. Decide first whether or not to open the EAPI-3 feature list at all. I'm against re-opening the feature list for EAPI-3, let's get EAPI-3 finally implemented and put this on the agenda for EAPI-4. I don't see the pressure to allow bash-4.0 stuff now. Define EAPI development/deployment cycles - Goal: Start discussion about EAPI development/deployment. For example: Collect problems of eapi introductions in the past, like reverting ebuilds to former eapis to get them stable, not waiting for the pm support a certain eapi before requesting stable keywords for ebuilds using the new eapi, Collect problems of EAPI development like feature-freeze, late feature removals (due to implementation problems). Eventually develop a lightweight EAPI development model. The main problem is that there is no deployment process for newer EAPIs specified right now. In the past we had something like there must be two releases (stage sets) including a Portage version supporting new features before people were allowed to use new features in tree. We had a timeframe of something about a half year between introduction of new features and usage of them. At least in theory. While having such a longer timeframe would make the deployment of new EAPIs somewhat easier (especially the special cases when newer versions of a package were migrated to a shiny new EAPI which isn't supported by a stable Portage yet and there's a need for quick versions bump due to security bugs) I think something inbetween that old process and the currently used one would be useful. For example something like: New EAPIs can be used in tree once a Portage version supporting that specific EPAI has been marked as stable plus a transition period of - say - 4 weeks after the Portage version has been made stable on the first architecture. And for EAPI development: I did dislike the google spreadsheet which has been used for EAPI-3 and don't think this has proved to be useful. If we do opt for any public collaboration development process (instead of say some file in $SCM) we should use a simple Wiki and be done. Tracking changes made to that document is a requirement from my pov. Using bugs for each feature and an EAPI tracker bug would be another possible way to organize this. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for June 11
Ciaran McCreesh wrote: Oh please no wiki. Whatever. My requirements are quite simple: public accessible, no accounts needed on 3rd party systems (like Google) to add feature requests or comments and changes must be traceable. Using bugzilla fits those criteria as well. The problem for EAPI 3 was that feature requests were on a google spreadsheet, and on bugzilla, and on a pms draft branch, and on a text file in various people's devspaces. Agreed. The workflow that'd be easiest is: * Requests go onto bugzilla, where they could be nicely organised into can do this now, probably not doable in the timeframe we're looking for and not detailed enough to be usable. * can do this now requests are added to a tracker bug for the upcoming EAPI. * We get rough diffs for PMS for everything in the can do this now category, and give them all an arbitrary codename that in no way describes the feature (so that certain people can't vote and discuss things based upon what they think the feature is without bothering to find out if it's anything to do with what they assume). * Based upon developer feedback, the Council rates each of those codenames as yes, no, whatever or needs more discussion. For those that need discussion, the people who voted for discussion explain what they think needs discussing, and we sort that out. * The PMS people come up with exact wording for things that are mostly yes. * The Council votes for final approval, pending Portage implementation. Looks good so far. * Portage implements it in ~arch. People start using it in ~arch. I'd propose: Portage implements it in ~arch. People can start using it in overlays. * Portage goes stable. People are allowed to start using it in stable for things that aren't deps of anything super-critical. I'd propose: Portage goes stable. 4 Weeks thereafter people are allowed to start using it for things that aren't deps of anything super-critical. What we don't need is lots of people running around doing their own thing in different places. What we do need is for a single waterflow-like workflow with a good way of coordinating it that doesn't rely upon the PMS team chasing everyone up and trying to keep track of everything. ack. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for June 11
Roy Bamford wrote: What about the case where the new EAPI breaks backwards compatibility with existing package managers, as would be the case with glep 55? Its quite true that such changes can be introduced after a wait and only upset late adoptors. By implementing the key feature of glep 55, which is making the EAPI known to the PM without sourcing the ebuild, we would only need one last wait to introduce new features in this way in later EAPIs.PMs would then know the EAPI in advance and ignore ebuilds using EAPIs they don't understand. But still then the special case I mentioned comes in. Newer version migrated to newer EAPI. Urgent bump for security reasons is necessary. Backporting the ebuild is necessary. Not that likely, but iirc we had that special case for EAPI-2. Putting in a wait for 4 or 8 weeks or whatever doesn't cost us anything but does simplify things and gives us a clear deployment process. I do know we have developers with nil interest in our stable branch, but we also have users heavily relying on our stable branch. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
Heya, thanks for bringing this up! Doug Goldstein wrote: All, The current council meetings have gotten completely out of hand for weeks meetings have become nothing more then a continuation of the senseless bicker-fest that have become the e-mail threads on GLEP54, GLEP55, and EAPI-3 without any real progress or sense coming of them. It's taken me a little bit to step up and put a stop to it but I fully intend on putting a stop to it. Remove EAPI-3 from that list (as we got that off our desk for now, but the whole process could've been much easier, yeah ...), but in general: the neverending GLEP54/55 stuff isn't fun and i don't see us getting any further on that anytime soon. 1) Agenda Topics are posted to the appropriate mailing lists at a MINIMUM 7 days prior to the meeting. (That means the agenda must be formed by this Thursday). 1a) Any changes to the agenda should be ACK'd by the council members (off list via the council alias). Changes can not occur less than 48 hours from the meeting. ack 2) The #gentoo-council channel become moderated as we had discussed several times in the past. The experiment do keep meetings unmoderated was quite successful in the beginning nearly a year ago, i'd like to get back to the beginn of our experiment instead of just +m. If it proves not to work ... well we still have +m. 2a) Topics will be brought up and people wishing to address the council and the developer body at large should speak to the day's appointed moderator. We can take turns or I can do it (maybe it'll keep my head from banging against the keyboard as it has in the past watching the various non-council members argue completely non-agenda items back and forth). 2b) Requests are made in tells and honored in turn. The moderator will announce to the channel who wishes to speak and the order they are in and will efficiently work through the list. If you can not remain on topic, you will lose your voice. See above, looks good to me and would help in making meetings more productive, just marking the channel +m is something we can do if real moderation doesn't work. 3) Once discussion on the topic has concluded, the council members will vote on the actions requested by the developer body. That does not mean it is time for council members to concoct an entirely new plan by the seat of their pants... which leads me to the next topic. Add: Things to vote upon must be clear and precise worded. Discussing for half an hour of what's been voted upon and changing votes for several times is a huge waste of time (like we had 2 1/2 weeks ago). 4) Council members will now be expected to ACK the agenda on the appropriate mailing lists at least 48 hours prior to the meeting. If you can't, let the council know. You should be able to do this without relying on your proxy, but your proxy may do this for you as well if you have an extended away. 4a) Failure to ACK the agenda will be noted on the meeting minutes. 4b) Council members will be expected to formulate their thoughts in reply to the agenda items and to research the discussion they wish to have on the mailing list PRIOR to the meeting and not fly by the seat of their pants. 4c) The first I heard of this and I need 4 weeks to research this. or any variation of the quoted statement is no longer a valid statement. The point of the meeting is to weigh and debate the items before us now. Do your research PRIOR to the meeting, not during. ... and ack. wkr, Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
And here we go, these are the ones I'd like to nominate: * dev-zero, well because ... i'd like him to be on the council again! * ulm because I think he's an excellent addition to the council * amne, because I want him to stop slacking :P that's it for now :) wkr, Tobias Am Montag, den 01.06.2009, 10:48 +0200 schrieb Patrick Lauer: People I nominate: * leio / mraudsepp, because he's done a really good job protecting the distro's interests * Cardoe, because he is working goal-oriented and doesn't care about the wargharbling and instead goes for restults * lu_zero, because he's done a good job and brings in his own ideas without going religious on people with different opinions * dertobi123, because he's done a good job and keeps organizing the Gentoo presence on german open source events * ulm, because he's a good fellow that deserves to show what he can do on the council after being pulled in for the rest of the term to replace dberkholz * solar, because he knows how things work behind the scenes (infra, portage) and doesn't tolerate infinite discussions * grobian, because he's shown leadership and dedication with Prefix and the other things he got involved with * quantumsummers, because he has shown dedication and reliability * scarabeus, because he knows what he wants and promised to beat me up if I didn't nominate him * tove, because he has done an awesome job keeping perl alive and has shown consistent sane opinions in technical discussions * zmedico, because he has managed to beat portage into a really good shape and keeps adding features that make users happy signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
Am Donnerstag, den 14.05.2009, 20:48 +0200 schrieb Thomas Sachau: This is already done. darkside/idl0r did/do suggest sunrise to all maintainer-wanted bugs, that meet some specific criteria. noticed that, and i'd like to give a thanks guys for doing so :) But have to say, while hundreds of messages where sent, there is not much response from this until now. not much is not no response, maybe it would make it easier for users to get active with sunrise if we'd have a shiny x steps to commit to sunrise document maintained by our docs project (and also translated!). Plus from what i've seen on the overlays' sunrise wiki one who'd like to contribute needs to got to IRC to ask for an account - which most likely lots of possible contributors are not familiar with. Make it as easy as possible for those people! - oh and: promote it more actively. wkr, Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] proposed email - Dropping old kde3 eclasses from the tree
Am Freitag, den 01.05.2009, 22:33 +0300 schrieb Petteri Räty: #gentoo-dev 20:19 @zmedico jmbsvicetto: it's only an issue for people upgrading from less than portage-2.1.4, which is pretty rare nowadays For the KDE team, It's an issue for people who have packages in vdb emerged with portage older than 2.1.4 (if this was the version where the env started being added to vdb). I have been maintaining the position that nuking eclasses doesn't really provide enough benefits to bork these installs. I recommend just making the eclasses unusable for emerging stuff and keeping uninstalls working. Agreed on that, plus we don't have any *real* numbers on how rare anything less than 2.1.4 *really* is these days. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] PMS EAPI 3 more or less ready
(Somewhat late, but here we go ) * PKG-PRETEND critical * SLOT-OPERATOR-DEPS yes * USE-DEP-DEFAULTS critical * DEFINED-PHASES critical * PROPERTIES critical * SRC-INSTALL critical * CONTROLLABLE-COMPRESS critical * DODOC yes * DOINS yes * ANY-USE whatever * BANNED-COMMANDS yes * DOEXAMPLE no * DOINCLUDE whatever * UNPACK-EXTENSIONS yes * ECONF-OPTIONS yes * PKG-INFO critical * PROFILE-IUSE-INJECTION yes * AA yes * KV yes * REPLACE-VERSION-VARS whatever * S-WORKDIR-FALLBACK whatever * UNPACK-IF-COMPRESSED whatever * RDEPEND-DEPEND yes * DIE-ON-FAILURE critical * NONFATAL yes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ioannis Aslanidis wants to share their location with you on Google Latitude
Would you please stop that? kthxbye. wkr, Tobias Ioannis Aslanidis: Ioannis Aslanidis (aslani...@gmail.com) wants to start sharing their location with you on Google Latitude. You need to sign in to Latitude with a Google Account (e.g., @gmail.com) and invite Ioannis Aslanidis. To get started, or to learn more about Latitude, click the link below. To get Google Latitude on your phone, click or type in the link below from your mobile web browser. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] One-Day Gentoo Council Reminder for April
Mike Frysinger wrote: This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ I'd like to vote on whether to approve GLEP 54. As for EAPI=3 the only thing I've got a question on for now is doexample. I'm not sure if we really need an additional doexample as from my understanding examples are in most if not all cases docs which then could be installed using dodoc. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo as Meta Distribution?
Michael Haubenwallner: Hi people, I've been cooking a thought for some time now, and now I'm inviting you to have a look at and share your thoughts about it: The title could be somehow like: How to use Gentoo, the Meta Distribution to create my own Enterprise Distribution? When I say my own Enterprise Distribution, I mean doing my own arch testing and stable keywords, for a small number of packages - less than 200 here including @system. Doing my own stable keywords does not mean to throw away upstream (=Gentoo) keywords, but reuse them as unstable keywords for my distribution, so my distro-users can easily emerge packages which are either upstream-stable or even -unstable, assuming they know what they do then. [...] Thank you for your time reading until here! Michael, this sounds like a *really* good idea to me (I guess I can think of your background you plan to use this for), this would make Gentoo a bit more meta and would also make it easier to build distributions upon Gentoo. I look forward to discuss this idea in real life in Graz next month with you and GLEP it :) wkr, Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
Am Montag, den 09.03.2009, 10:12 +0100 schrieb Michael Haubenwallner: On Sun, 2009-03-08 at 21:22 -0700, Donnie Berkholz wrote: I think the idea of ebuilds as scripts showing directly how to build software is a core part of the Gentoo build-system philosophy. This proposal pushes ebuilds toward a formatted file that is not a script. Instead, it is more like an Ant XML file that more abstractly describes a build. I think this is the wrong direction for ebuilds because they should directly resemble how software is built by hand. Fully agreed here, keep it simple software. Even if there are slightly more bits to write in the ebuilds. dito, fully agreed. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] prepalldocs is now banned
Am Mittwoch, den 18.02.2009, 12:26 +0200 schrieb Petteri Räty: Michael Sterrett wrote: I added a prepalldocs function to eutils.eclass to provide the functionality. It implements the behavior of the current stable sys-apps/portage-2.1.6.4. Have fun, Michael Sterrett -Mr. Bones.- mr_bon...@gentoo.org I don't think developers should add stuff to eutils.eclass without prior review on this mailing list. Agreed. Besides that, replacing a workaround with another workaround isn't a sexy way to solve something ... Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] Re: [gentoo-dev-announce] Last Rites: games-puzzle/ksudoku
Markus Ullmann wrote: +# Markus Ullmann jo...@gentoo.org (31 Jan 2009) +# Mask for removal in 30 days (found its way into mainline kde as kde-base/ksudoku) +games-puzzle/ksudoku + Wouldn't it make much more sense to package move ksudoku then? Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] PR Project Activity Issues
Alec Warner wrote: Why do you not tend to commit news or approve things? PR@ is a nghtmare of spam and what I'll term 'crap.' having real things marked as such with informative subjects would be useful. having some kind of rotation would be useful having some kind of vague 'we will read and respond within 3 days unless its a holiday' would be useful. Right now the expectations of pr@ are non-existent and apparently think the mail is read and answered quickly. In reality only Donnie reads it and replies; he has a busy as hell personal life and I'm surprised he manages to read it at all. Oh, it's not only Donnie - there's also Kurt replying and sometimes it's even me and some other people as well. I'm following the pr@ alias for quite some years, mainly looking for things or questions having something to do with European events, things and $whatever. I don't have commit access to the website part of our CVS though - I did ask for commit access exactly one month ago when Donnie asked for someone posting the January Bugday news item. Simply put: there are other people following the pr@ alias. So I would like to set expectations ;) One expectation would be to build some pr *team*. Another thing would be to have an issue tracker like rt or otrs. This would make sure items are answered (and if it's only a quick reply stating we did receive your mail, but we need to look at your questions and will reply in the next $number of days) and would allow to use boilerplates to answer standard questions. This would also allow some kind of escalation for tickets which are due. Another thing I'd like to see are regional pr contacts - guess it's the third or even fourth time I'm suggesting this over the years :P What's also missing and that's the topic the most questions to pr@ are about is a process on when and how someone is getting added to the Where to get Gentoo page [1] (mostly CD distributors). Anyways, that'll all be nice things - but it all comes down to a PR *team* which is obviously missing. Tobias [1] http://www.gentoo.org/main/en/where.xml signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22
Ulrich Mueller wrote: On Thu, 22 Jan 2009, Tobias Scherbaum wrote: - PMS, bug #250077: Do we need to get involved in this? (-dev) We haven't been asked to get involved, therefore we don't need to. http://thread.gmane.org/gmane.linux.gentoo.devel/59321/focus=59324 well, http://article.gmane.org/gmane.linux.gentoo.devel/59428 We do have the procedure you did ask for and I personally tend to agree with what Donnie said. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog use.local.desc
Matsuu Takuto (matsuu) wrote:
matsuu 09/01/02 16:19:02
Modified: ChangeLog use.local.desc
Log:
Adding local use flags for app-i18n/ibus-table-{erbi,wubi,zhengma}.
Please add local use flags to metadata.xml ... see GLEP 56 for
reference. http://www.gentoo.org/proj/en/glep/glep-0056.html
Tobias
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Automatic filing of stable requests
Thilo Bangert wrote: Now what do people think about extending metadata.xml so that you could have these bugs filed automatically when there are no open bugs? Something like a auto-stable-request enabled=true/ element with the DTD setting the default as true and you could just use a auto-stable-request / shorthand. good idea. +1 I'm all for it. It would need to take version restrictions -- for example, I may be willing to have xorg-server 1.5.x go stable but not 1.4.x. perhaps auto-stable should be the default (not needing the tag), only allowing things to be masked from it. I'm not sure if it's really useful to have this as a default - for example i keep nagios-3 packages intentionally ~arch for now. Tagging them as not ready for stabilization yet would introduce something between ~arch masked and package.mask - i don't think that's worth the effort. From both a maintainers and arch-developers view: I'd like to see automatically generated stable requests, but I'd leave it up to the maintainer/herd/team to add architectures after a quick review (also if there's a auto-stable-request tag set in metadata!). Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Monthly Gentoo Council Reminder for December
Donnie Berkholz wrote: On 14:47 Mon 01 Dec , Ciaran McCreesh wrote: Please give the OK on the following, assuming no objections crop up before then: * [RFC] Label profiles with EAPI for compatibility checks (revised) http://archives.gentoo.org/gentoo-dev/msg_930f58fcebcbbcbe523c001f2c825179.xml * EAPI change: Call ebuild functions from trusted working directory http://archives.gentoo.org/gentoo-dev/msg_5ba467bbd5a0820e040210683702a67f.xml * RFC: DEFINED_PHASES magic metadata variable http://archives.gentoo.org/gentoo-dev/msg_8c34d8efbc0d31ab28c517403dc83f62.xml These things, plus updates on the bugs council@ is CC'd on, will compose our agenda. FWIW, I'm fine with all 3 of the above. ditto. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
Jan Kundrát: Diego 'Flameeyes' Pettenò wrote: I have a very quick proposal: why don't we move the packages' homepage in metadata.xml (since it's usually unique for all the versions) I believe the reason was that HOMEPAGE might change with new versions and that metadata.xml didn't (doesn't?) support version-specific data. In most (nearly all?) cases a HOMEPAGE change does also affect older versions. Does someone have an example where older versions stay at an old homepage and newer versions moved to a new homepage? Which (and how many) packages would be affected by that? If this does affect a larger number of packages (i doubt so) we might add something like this: link type=homepage:oldhttp://package.oldbarfoo.org/link or we allow more than 1 homepage item to be specified of which we can use the title attribute to describe for which versions this homepage item applies. Anyways, all of these would only be quick hacks for a rather short timeframe which it takes to stable a new version and remove the older one. In general I do like that proposal, especially the addition of further links for bug trackers, forums, irc-channels, gentoo-specific documentation and so on. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
Matti Bickel wrote: And while your proposal sounds more compliant to the DRY principle, i would object it on the basis that it makes a single ebuild actually harder to understand as you have to read (1) eclasses, (2) -base.ebuild and (3) -version.ebuild. That's quite exactly what I wanted to write - plus this -base.ebuild thingy would only make sense if we also allow versioning of -base.ebuilds. And then we're quickly speaking of package-based eclasses instead of -base.ebuilds. If we're speaking of a list of whishes for 2009 - i'd prefer to see eclass versioning instead of -base.ebuilds ;) Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future
Serkan Kaba wrote:
I don't know if there are others but I can give one specific example,
sun-{jdk,jre-bin} where homepage differs in SLOT's
1.4 pointing to http://java.sun.com/j2se/1.4.2/ , 1.5 to
http://java.sun.com/j2se/1.5.0/ , 1.6 to http://java.sun.com/javase/6/
and 1.7 will probably have something new.
A special case in which HOMEPAGE=java.sun.com might work as well? ;)
Ok, of course this on purpose and might be of benefit to be pointed to a
specific website in that case.
But what about additional slot or version attributes like
link type=homepage slot=1.4http://java.sun.com/j2se/1.4.2//link
(or a version attribute)? If slot and version aren't specified they'd be
interpreted as wildcards.
Tobias
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future
Diego 'Flameeyes' Pettenò wrote: Tobias Scherbaum [EMAIL PROTECTED] writes: But what about additional slot or version attributes like link type=homepage slot=1.4http://java.sun.com/j2se/1.4.2//link (or a version attribute)? If slot and version aren't specified they'd be interpreted as wildcards. link type=homepage restrict=dev-java/sun-jdk:1.4 The restrict attribute exists already and it's better to reuse the same code, isn't it? In general yes, but in that case you're duplicating info like dev-java/sun-jdk unnecessarily. Reducing this to restrict=1.4 isn't easily readable as you'd need to know that restrict would specify a slot. If your plan is to make it easier to find useful information about a package (without using a fancy frontend, just reading the metadata.xml with $EDITOR) slot=1.4 (or a version attribute) might be a tad more human readable. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Time to say goodbye
Marius Mauch wrote: So I guess that wraps it up. It's been a nice ride most of the time, but now it's time for me to leave the Gentoo train. ... and time for another sad to see you go. :( I'd link to thank you for contributions to Portage - but also for being a very active forums user as well. It would be nice to see you still being active in the forums - or to meet you again at FOSDEM :) Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Re: [gentoo-project] Gentoo Council nominations are now closed
Mauricio Lima Pilla wrote: What are the nominees intending to do if they are elected? I miss the manifests. dev-zero and leio posted their manifests, they're available on the elections webpage: http://www.gentoo.org/proj/en/elections/council-200811-nominees.xml Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] An official Gentoo wiki
Ciaran McCreesh wrote: On Tue, 11 Nov 2008 18:45:32 -0500 Mark Loeser [EMAIL PROTECTED] wrote: What are others feelings on this? What issues do you see with having a wiki? Do you see anyway to resolve the issue you see with us having a wiki? What will policy on articles that are horribly dangerous or outright wrong? Is Gentoo prepared to block or warn about articles that recommend stupid things? If a warning is used, what will be used to distinguish between a generic wiki, not necessarily checked by sane people and a article known to be horrible? Wikipedia started using an extension for marking pages as validated. See [1]. This would allow us to setup a group of trusted people (developers, long-time users, well-known contributors - for example) who would be able to review pages and tag them that way. Non-reviewed pages could show a header then clearly stating that this specific page hasn't been reviewed and might contain inaccurate information. Tobias [1] http://www.mediawiki.org/wiki/Extension:FlaggedRevs signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
Mark Loeser wrote: Removing Stable Ebuilds If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY choose to delete an older version even if it is the most recent stable version for a particular arch. What if this would break deps or it's a very common package for example belonging to the set of system packages? If we would opt for such a fixed timeframe for architectures teams to fix bugs I'd like to rate those bugs at least partially like security@ does - that would allow us to have different timeframes for stabilization depending on how much the package in questions is (expected to be) installed at our users' systems. In my opinion we would need to address two main concerns with this discussion: 1) What can we do to help understaffed architecture teams? What about using a tinderbox (yeah, i know - we have lots of tinderboxes already around) which automatically (re)builds stable-candidates and those of the candidates which a) includes a test phase and b) pass that test phase might be stabled by the maintainer/herd and not only the architecture team, for example? 2) When do we move an architecture back to ~arch? We would need to define a threshold of when an stable architecture has to enter a probation period (and who and what's going to start that process) and a timeframe after which either the architecture is moved back to ~arch or the architecture team has proven that it is able to maintain stable keywords (define who's going to decide this). Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Flags to punt (including: kerberos USE flag)
Josh Saddler wrote: Long as we're discussing things to punt, here's some stuff to kick out of the desktop profile: and for the server profiles there's mailwrapper - merely broken, nothing useful at all Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] EAPI-2
Luca Barbato wrote: Jorge Manuel B. S. Vicetto wrote: Hi again. Quoting Zac earlier in #gentoo-portage: 21:46 zmedico jmbsvicetto: I think we essentially have a spec already that people can agree on. just take my draft and subtract the eapi* functions and the gitweb unpack extension. I don't see any problems with it. +1 Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] mail-filter/spamassassin: maintainer needed
Torsten Veller: I guess some of you use spamassassin. Does anyone volunteer to maintain it? Search bugzilla for open bug-reports. I (or much better net-mail) can take it. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [GLEP 56] metadata.xml status
Doug Goldstein wrote: It seems Mr_Bones and I got a bit crazy and finished off the rest of the tree, along with some help from jer. Thanks to everyone that converted a package, and a double thanks to anyone that converted a category. GLEP 56 is now done. Thanks Doug (and also everyone else involved)! Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for August 7
Mark Loeser wrote: I personally don't see why they should be allowed to stay part of our communication channels where they have caused problems bad enough to get them retired. With that being said, I think the same technical issues come into play here as with banning someone from Gentoo entirely. I agree on this. I'd limit this ban to channels where they have caused problems though (or channels which they've been taking part of), banning them on each and every #gentoo-* channel is just an unnecessary overhead imho. And for the given technical restrictions they'd be banned as suggested, when they are coming back using another IP or another nick the same rules would apply as for every other user - warning and ban if they're misbehaving. I am not sure how we would be able to enforce this across the board for forcefully retired developers. It's not really possible without some huge work overhead to fully ban someone - therefore given limitations as described above would apply. Everything else is not doable from my pov. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for August 7
Mark Loeser wrote: Lukasz Damentko [EMAIL PROTECTED] said: 1. I'd like to ask Council to discuss possible reactions to our [...] Due to their privacy policy I don't think we'll ever be able to get adequate explanations from Freenode staff when our devs are banned. I think that's a limitation which will also applies to other IRC networks, therefore we have to live with that limitation or run our own IRC network. I can't say that I prefer the latter one ... we're a quite good in running our distribution - but would we be also that good in running our own IRC network? I guess not ... 2. I want Council to consider moving their meetings somewhere where [...] If for some reason a developer was unable to attend a meeting due to being klined or the internet being FUBAR'd, I know that I have my IM details available in LDAP for that dev to be able to contact me, or they could send the entire council an email. I don't think setting up our own IRC server is worth the trouble for this small purpose. +1 on that 3. I want Council to consider creating and using irc.gentoo.org [...] I like this idea. again +1 on that spb rose some concerns in the meeting with regards to some users thinking that if they came onto irc.gentoo.org and joined #java that it would be a Gentoo java channel, but it doesn't seem like Freenode considers this to be much of a problem. For evidence of this: http://freenode.net/acknowledgements.shtml They thank projects for pointing their domains to them, so I believe that the network as a whole shouldn't have a problem with this. If someone thinks I'm misunderstanding what they mean on that page, please let me know. Given the fact that the concern spb raised in the meeting is a non-problem, at least until Freenode changes its policy in that aspect, i see no problem with pointing irc.g.o to irc.freenode.net. Plus irc.g.o. in some way points to Freenode servers already irc.gentoo.org canonical name = irc.osuosl.org. irc.osuosl.org is an A record for 140.211.166.3 and 140.211.166.4 which are both Freenode boxes. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]
Doug Goldstein wrote: What is the benefit? Regards, There is none really. Allow all use flags to exist in metadata.xml. It's really more of a clarification to the GLEP if this is allowed. Agreed, it has no benefit at all plus would lead to some kind of useless duplication of information. Stating flag name='png' / in metadata.xml for global use flags makes basically no difference to IUSE=png, except that we already have the latter one. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] The Plethora of Patches
Santiago M. Mola wrote: I think that's all we need in order to know how were things when the patch was added and if it needs to be pushed/tracked upstream, removed in the next version of the package, etc. Some of us already put these kind of headers, or at least an URL to upstream bug or a meaningful source of info about the patch. A short description possibly including a reference to an upstream or Gentoo bugreport prefixed to every epatch call should be our minimum standard. Working on packages whose maintainers are MIA isn't always that simple - but it's even worse if you have to check a number of patches to find out what they are for, since when they are in and what their status is ... However, tracking the status of every patch since its inclusion in portage until it's removed would be a huge work overhead... and I doubt it's worthy. I don't think it's a huge work overhead, it'll take an additional minute per included patch to include a minimal description into the ebuild(s) and use a standardized header for the patch. Compared to the time one needs to spend when searching for information on that patch somewhen later on it's worth every minute. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Suggestion: remove app-office/borg from portage.
John Brooks wrote: Random idea: How about a different bug assignee for maintainer-needed packages with provided ebuilds/patches? Either something generic, or try to go for something more category/package specific (herds, etc). Lots of work for bugwranglers, though. There is a huge difference to developers between an unmaintained package with no progress and just looking over an ebuild that has been used successfully by several people. No need for an additional mail/bugzie alias here, we could simply use a KEYWORD like the existing 'Inclusion' (which isn't used that much for now, 63 open bugs have that keyword) or a new 'HasPatch' as a counterpart for 'NeedPatch'. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] The Plethora of Patches
Santiago M. Mola wrote: On Tue, Aug 19, 2008 at 12:02 AM, Tobias Scherbaum [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: However, tracking the status of every patch since its inclusion in portage until it's removed would be a huge work overhead... and I doubt it's worthy. I don't think it's a huge work overhead, it'll take an additional minute per included patch to include a minimal description into the ebuild(s) and use a standardized header for the patch. Compared to the time one needs to spend when searching for information on that patch somewhen later on it's worth every minute. Of course, puting a header with info in every patch is not a work overhead and I'd say it should be policy. What I meant is that it's no worth to track the status of every patch after it's added, as was suggested. Agreed. Everyone of us is doing some kind of status tracking for each and every patch at least for every version bump, additional status tracking like Andrew suggested would be a good thing (tm) but is plain impossible to realize for now given the fact we're lacking the needed manpower. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [RFC] Add support for package.keywords in profiles?
Zac Medico wrote: Does package.keywords seem like a good solution for the types of problems it's meant to solve? Would anybody like to discuss any alternative approaches? I think it's a good and easy solution to the problem(s) solar described in #55321. But as Marius [1] said this can become quite confusing very quickly, therefore we would need to limit it's usage to uclibc/hardened/$special sub-profiles imho. Otherwise it gets more of a pain in the ass. Tobias [1] http://bugs.gentoo.org/show_bug.cgi?id=55321#c11 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
Fabian Groffen wrote: On 05-06-2008 02:35:16 -0700, Josh Saddler wrote: Now that nominations are officially open, I nominate the current council members (again): I nominate: dertobi123 Though I'm in favor of just re-electing the current council members as they did a very good job in general, I'm going to accept your nomination and run again for the council. My manifesto is (still) available at http://www.scherbaum.info/~tobias/manifesto Thanks! Tobias -- Gentoo Linux - Die Metadistribution http://www.mitp.de/1769 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] packages up for grabs
Mike Frysinger wrote: net-ftp/ncftp i can take this one wkr, Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] New developer: Tobias Klausmann (klausman)
Am Montag, den 10.03.2008, 23:02 +0100 schrieb Lars Weiler: * Petteri Räty [EMAIL PROTECTED] [08/03/10 23:13 +0200]: One of those people working on those weird paper weights. This time our monkey comes from the world of alphas. Tobias hails from Germany (there seems to be no end). Finally! Nice to see you here as well :-) Indeed! Welcome aboard, Tobias :) wkr, just another Tobias ;) -- Gentoo Linux - Die Metadistribution http://www.mitp.de/1769 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] retiring + looking maintainers for sendmail, tenshi, scapy, ftester
Heya, Andrea Barisani wrote: Hi folks, I'm retiring. Sorry to see you go - i'd like to especially thank you for your ldap+ssh +lpk effort! thanks! :) I was maintaining the following packages: app-admin/tenshi (note: I'm upstream as well) I can take a look at tenshi if noone else is interested. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/nagios-plugins: ChangeLog nagios-plugins-1.4.10-r1.ebuild
Donnie Berkholz wrote:
chown root:nagios ${D}/usr/nagios || die Failed Chown of
${D}usr/nagios
chown -R root:nagios ${D}/usr/nagios/libexec || die Failed Chown of
${D}usr/nagios/libexec
chmod -R o-rwx ${D}/usr/nagios/libexec || die Failed Chmod of
${D}usr/nagios/libexec
chmod 04710 ${D}/usr/nagios/libexec/check_icmp || die Failed Chmod
of ${D}usr/nagios/libexec/check_icmp
This may not be worth changing, but if you're ever working on it,
fperms/fowners could be nice to use instead of these. It lets you clean
out all those references to $D.
I'll take a look at it, thanks! :)
wkr,
Tobias
--
Gentoo Linux - Die Metadistribution
http://www.mitp.de/1769
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] New developer : Timo Gurr (tgurr)
Denis Dupeyron wrote: It's my pleasure to introduce Timo Gurr (tgurr) who will join us as a new developer. He will work primarily on KDE and printing. Timo lives in Neckarsulm, Germany, and works as an IT technician in a local city administration near his home. He finds his job very interesting and loves it, and even runs some Gentoo machines there. His interests are very wide-ranging and he likes to play a good game from time to time. This makes him believe he is a pretty normal guy. Well, let me tell you something, Timo. You've just entered Gentoo-land, so please leave all normality at the gate. Thanks for your understanding. Let's all give him a very warm welcome. Welcome Timo! Seeing that you're working in the local city administration ... gentoo-devs-working-in-public-services++ :P /me mumbles something about not replying to the dev-announce-list ... Tobias -- Gentoo Linux - Die Metadistribution http://www.mitp.de/1769 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] New Developer: Christian Hoffmann (hoffie)
Christian Heim wrote: It's my pleasure to introduce to you Christian Hoffmann (also known as hoffie on IRC), our latest addition joining the PHP herd. Christian is joining us from Bamberg (which is about 60km north of Nuremberg, which happens to be in southen Germany), where he's currently enjoying high school to get his graduation (or for those capable of understanding german :'Abitur') done. When Christian isn't around computers (and fixing PHP bugs - hah!), he's enjoying singing in a choir, reading a good book or simply working in the garden. So please welcome Christian as a new fellow developer among us ! Welcome aboard Hoffie! :) Tobias -- Gentoo Linux - Die Metadistribution http://www.mitp.de/1769 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Nominations Update
Heya, Christina Fullam write: Most who have accepted havent told us why we should vote for them. While that information is not required perhaps it should be if we are to make intelligent votes - sorry this isnt a popularity contest so give us some content to review. I put my little manifesto up here: http://www.scherbaum.info/~tobias/manifesto Tobias -- Gentoo Linux - Die Metadistribution http://www.mitp.de/1769 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] net-mail/cyrus-imapd needs an active maintainer
Jakub Moc wrote: This ebuild has a security bug open for almost one year (Bug 142817), plus lots of other bugs as well. If you are interested, please see http://tinyurl.com/32webs I'll take a look at it. wkr, Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
Markus Ullmann wrote: nominating: others are nominated already ;) d'oh, forgot fellow dertobi123 Thanks, I accept the nomination. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Non-new developer: Tobias Heinlein (keytoaster)
Denis Dupeyron wrote: Tobias tells us his hobbies were computers, programming, reading, meeting friends, and sleeping. Which means it's now down to computers and programming only. So please, everybody, give a warm non-welcome to Tobias. Congrats! :) Und mach nix kaputt :P Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] net-dns/bind{,-tools} needs an active maintainer
Konstantin V. Arkhipov wrote: i'm too busy with real life atm, is there anyone willing to help with bind's maintaining? What's the current state of both packages? i.e. lots of open bugs? How much attention do these packages need? wkr, Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] net-dns/bind{,-tools} needs an active maintainer
Jakub Moc wrote: Tobias Scherbaum napsal(a): Konstantin V. Arkhipov wrote: i'm too busy with real life atm, is there anyone willing to help with bind's maintaining? What's the current state of both packages? i.e. lots of open bugs? Not really... 8 bugs altogether, 2 enhancements, 2 stabilization, 1 LDAP-related, 2 DLZ related, 1 hardened. http://tinyurl.com/3cwhjv Thanks Jakub :) I saved this search-command and try to help w/ bind. wkr, Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Bye Gentoo!
Bryan Østergaard wrote: Good luck to all of you and may Gentoo development be as much fun for you as it used to be for me. Just as Marius already said, I usually also don't participate in the goodbye and thanks for all the fish-threads - but this one is kinda special. Bryan is one of the few non-German Gentoo Developers I met several times and we had much fun every time - at least this was my impression. I was already looking forward for meeting you again at the UK Meeting in July ... so ... yeah ... I'm really sad to see you go :( For whatever you're doing next I'd wish you as much luck and fun as I can. Thanks for your contributions and being an important part of Gentoo in the past few years! Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] *DEVELOPMENT* mail list, right?
Joseph Jezak wrote: I like this thread! Indeed! This thread is fun - and fun is what Gentoo should be about. The PPC team had a bugday yesterday and managed to get almost 70 bugs off of our list of open issues! Thanks to nixnut, mabi, dertobi123 and ndansmith for helping to clean up the bug list. :) Well, it was a merely informal bugday, at least for the ppc people. But it was fun though and we were in need of such an event :) Conclusion: Let's have more bugdays! ;) Personally I'm fighting with getting the HPPA parts of the upcoming release done in time - looks quite promising as of now. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] [RFC] Maintainer Timeout
I want to propose a Maintainer Timeout such as FreeBSD. If a maintainer or herd does not fix (or assign/comment) a bug in a reasonable amount of time (2 weeks? 3 month?) any developer can fix it (or a pre established group of developers such as QA) There's a little difference between does not fix and assign/comment, I'd appreciate if you could be a bit more verbose on that ;) wkr, Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] FEATURES to cut the excess in portage
Am Sonntag, den 05.11.2006, 20:08 +0100 schrieb Christian Heim: On Sunday, 05. November. 2006 19:02, John Jawed wrote: Two patches which allow a user to bypass files created with doman and dodoc in FEATURES: FEATURES=noman nodoc emerge -av foo http://jawed.name/dev/gentoo/nodoc.patch http://jawed.name/dev/gentoo/noman.patch Err, isn't current portage already having FEATURES=noman and nodoc ? At least last time I used it, it was there ... Don't forget about noinfo ;) Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] New developer: Christian Faulhammer (opfer)
Am Freitag, den 27.10.2006, 22:32 +0200 schrieb Christian Heim: Christian is currently studying mechanical engineering at the RWTH Aachen (that's in Germany!) and has been an arch tester for the x86-herd for quite some time - that's about 3 months. Welcome aboard, Christian! See you at LWE in Cologne ;) Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] New Developer: Matti 'mabi' Bickel
Living in Weimar and studying CS in Jena, he is going to join the German conspiracy. He is also a member of the local CCC there. Non-computer hobbies are reading (science, hitchhiker up and down, other novels, but of course also computer-related) and adrenaline sports such as table tennis. Hey, finally - after a very long time a new developer joining us from the Eastern part of Germany! I'll look forward seeing you again at the Congress in Berlin and hey - don't forget that you're (as a developer) are expected to join us at the events in Chemnitz and Dresden next year ;) Please give him a warm welcome! Willkommen! =) Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] RFC: Gentoo Commitfests
I think this is a fun way to build some team spirit. Thoughts? I think it's a *very* bad idea - both from a QA and a team spirit point of view. Instead of having such commitfests and bounties for the one who managed to get as many as possible commits done within - say - 5 minutes I'd rather suggest giving out bounties to developers who fixed important bugs and/or implemented often requested features, for example like GNOME did in the past. Bounties not necessarily as in money but as in hardware, books or $foo. Also those bounties mustn't be offered by the Gentoo Foundation, a near-ideal bountie-implementation would allow users/companies to offer bounties to get certain bugs fixed or pre-defined features implemented. Just my 0,02€ ... Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Resurrecting Project Dolphin
Hello folks, it's been a while since I stepped back as a Gentoo-developer (about 1 1/4 years) and in that time I did exactly zero. Good news to see you back in action, Benni! :) I hereby request every person make suggestions. Please note, that Dolphin will be a CLI-based CD only, so no X-Applications will be taken into consideration. In addition to the tools already mentioned by Tobias Klausmann I'd suggest the following: smartmontools, ipcalc, hddtemp, pwgen, screen, mailx, mutt(-ng?), net-snmp, bind-tools, telnet, whois, lsof I'd like bash as default-shell, but would also provide zsh (and tcsh?). Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
First of all, someone from infra/recruiters might please revoke my write access to gentoo/xml/htdocs/news/gwn. I'm no longer interested in contributing to the GWN. I also believe that when posting an article or interview, a copy should be sent to the relevant people to ensure that they are ok with what is being posted (my dev of the week interview, for example, was rather screwed up and misrepresentative). That's why Ulrich posts a draft to the core mailinglist, both for technical and grammar/spelling review. Also it is (at least it was) expected behavior, to give devs of the week (and devs mentioned or affected in/by other articles) a chance to review the article about them. If this wasn't the case with your article this is a problem we need to address. When someone contacts GWN to have something corrected, it would be appreciated were the GWN staff to at least deign to acknowledge receipt, even if for some reason they choose not to honour the corrections or post a retraction (although refusing to publish corrections is extremely insulting to those wronged). That's what I did in the past, of course: Only if I knew that there's something which needs to be corrected. (i.e. if there's a mail to the [EMAIL PROTECTED] alias). Another thing that concerns me is the way the articles are written. It is blatanly obvious that the GWN writers are not native English speakers as both the grammar and the flow of the articles is far from attractive. Having read through the archives, I notice that there was once a time when the GWN was a great publication, and I would like to think that it could become great yet again; in its current state, though, it is doing more harm than good. Once again: We have a draft posted to core to catch grammer/spelling mistakes. That doesn't improve the language used in GWN at all, but as you mentioned, none of us is a native speaker. I'm sorry for not being a native speaker. Finally, reading your mail makes me really angry. I'm seeing myself as a somewhat regular contributor to the GWN and would have expected, that someone who draws a negative picture of the GWN like you, tried to talked to me before posting such a mail. Also I see nothing the Council can decide to improve the GWN, besides stopping further GWN releases. I fully agree that we have lots problems and much room for improvement with the GWN, but I can't agree with the way your trying to achieve this. EOD for me. wkr, Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] New developer: Jokey (Markus Ullmann)
On Sat, 2006-01-28 at 12:37 +0100, [EMAIL PROTECTED] wrote: Please welcome Markus to the team. ... and once again a candidate for the one and only German conspiracy :) Welcome aboard, Markus! wkr, Tobias signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New Developer: Tobias Matzat (SirSeoman)
On Fri, 2006-01-06 at 23:55 +0100, Wernfried Haas wrote: On Fri, Jan 06, 2006 at 11:25:57PM +0100, Tobias Scherbaum wrote: Yo, Welcome Tobias! Oh no, not another Tobias! Isn't it a beautiful name? :P Tobias signature.asc Description: This is a digitally signed message part
