Re: [gentoo-dev] cvs.gentoo.org, git.gentoo.org, *.overlays.gentoo.org migration timeline ssh keys
On 8/19/14, 8:18 PM, Vadim A. Misbakh-Soloviov wrote: Btw, I've noticed git.overlays.gentoo.org moved to Hetzner. When I remember my expirience of work with Hetzner - I'm scary about Gentoo' infrastructure destiny. We are directly sponsored by them with at least another machine and are happy with their services. I had a conversation with CEO of my current DDoS-proof hoster and he expressed his desire to help interesting projects and asked about the necessary amount of sponsorship and it's terms (and conditions). So, can I ask you to provide some info about infra team hardware requirements (which amount needs to be sponsored) and if it is any sponsoring conditions that Gentoo Foundation can suggest to the sponsor (maybe some banner, or something like that)? Kindly consult past messages sent to the gentoo-announce list on that topic. Anyway, mainly I need the amount of hardware gentoo infra team requires to [strike]get rid of hetzner[/strike] meet their comfortable-work requirements? Then I can discuss it with hoster again and then bring together somebody from infra-team and hoster's CEO or CTO to discuss the terms themselves. Mind you, we are not going to 'ditch' sponsors, or randomly move services around just to use your preferred hoster, even if you establish sponsorship contacts with them. Alex PS. Your signature has a typo. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: News item: Removal of Ruby MRI 1.8; Ruby MRI 1.9 and 2.0 now default
On 08.03.2014 14:25, Alex Xu wrote:
On 08/03/14 05:37 AM, Tom Wijsman wrote:
On Sat, 8 Mar 2014 01:46:52 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
0 1 2 3 4
012345678901234567890123456789012345678901234
Ruby MRI 1.8 removal; 1.9 recommended default
(The latter is GLEP 42's max 44 chars exactly, and accurately
represents the recommended eselect ruby setting.)
$ x=Ruby MRI 1.8 removal; 1.9 recommended default ; echo ${#x}
45
Since you have started with 0 instead of 1, you have one character
more; thus we'll need to find another character to cut, since that
doesn't seem possible I suggest we drop the word default instead.
$ x=Ruby MRI 1.8 removal; 1.9 recommended ; echo ${#x}
37
$ x=Ruby MRI 1.8 removal; 1.9 now recommended ; echo ${#x}
41
I hereby make trademark claim to the name 'GLEP 42 Title Golf'.
Also, I doubt we're recommending 1.9 over 2.0 (or vice versa).
--
Alex Legler a...@gentoo.org
Gentoo Security/Ruby/Infrastructure
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: News item: Removal of Ruby MRI 1.8; Ruby MRI 1.9 and 2.0 now default
On 08.03.2014 14:52, Alex Legler wrote: Also, I doubt we're recommending 1.9 over 2.0 (or vice versa). scratch that, seems like we are (even though big users like rails actively push users to 2.0; but that's probably not important here) -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] overlays.gentoo.org restoration post-mortem
On 18.01.2014 06:23, Kent Fredric wrote: On 18 January 2014 18:02, Robin H. Johnson robb...@gentoo.org mailto:robb...@gentoo.org wrote: - More people need to use the infra-status page to learn about the state of Gentoo services. A service middle layer like fastly or cloudflare which could link to the infra page would be good here perhaps, so when an outage occurred ( at least on the web side ) appropriate links to infra could be given. And the infra status page is not exactly obvious. Its not listed on the gentoo sites list on the top right, and perhaps it aught to be. Ironically, the only site that was already using the Tyrian theme (i.e. the one with a top-right menu) was infra-status. Now with overlays using the new theme too, I've updated the list. (NB: During the outage, I added a link to the site from the g.o frontpage.) -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure
Re: [gentoo-dev] Regarding long delays on GLSA generation
On 18.01.2014 16:34, Pacho Ramos wrote: Was looking to existing gedit bug reports and I found: https://bugs.gentoo.org/show_bug.cgi?id=257004 That is only one more example of a really old bug report still opened and waiting for a GLSA. Was wondering what really causes this long delays, can't GLSA be done automatically? Nope. But we do make constant refinements to speed up the process. Would a GLSA even have any sense for cases like this (after 5 years) Yope. (I've answered this questions a trillion times by now, so care to use $searchengine?) Thanks for your help Not sure what you wanted to achieve by sending this email. Posting $old_bug assigned to a specific team to -dev to point fingers at them is just lame, as I'm pretty sure there's bug skeletons in every team's closet. Appreciatively of your appreciation of our efforts, Alex -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure
Re: [gentoo-dev] Regarding long delays on GLSA generation
On 18.01.2014 17:30, Pacho Ramos wrote: […] What I want to achieve is to try to get this problem solved, I don't think has any sense to have pending GLSA bugs waiting for ages (yes, ages), I see this for really a lot of packages, the pointed one was only one example, but there are many more (like glib, dotnet stuff...) Your message is profoundly lacking any proposed solutions, however it does contain plenty of complaining. That's not a good way to solve problems. Regarding sending this to the whole list (well, I don't understand why people in security team want to not get gentoo-dev ML involved), I simply did that as I though maybe some help/suggestions could be needed taking care clearly the security team is not able to fix this situation for really a long time and, hopefully, some other people could help with their effort and ideas to fix this long standing issue. Assuming that posing to -dev generates magical help or solutions is quite naive. You're not the first one to post here, but and you're certainly not the first one whose message didn't help in the slightest. Thanks for trying though. As others on the list have noticed, we are working on fixing things. Your diagnosis of us being 'clearly' unable to do so is quite unsubstantiated. You should understand that we can't just make a bug pile gathered over years disappear in one day. The issue is still present even if we don't talk about it and keep simply ignoring all bug reports assigned to security and accumulating for years. The idea is to try to solve the situation, not to point to you, I didn't pointed to you, you will know why do you feel offended about this. Noone's offended here. I'm just saying your email doesn't serve a purpose. If a -dev post was the solution, we'd have it by now. If you'd like to help in a way we actually think is useful, we'd be glad to have you fill one of our staffing needs posted or to engage in the discussions we have on the -security list and on IRC. -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure
Re: [gentoo-dev] Regarding long delays on GLSA generation
On 18.01.2014 18:38, Pacho Ramos wrote: […] Then, how are you finally going to fix this? Thank you for finally showing interest in anything we do. Here is how we are 'finally' going to fix this. Only for knowing, I still was seeing some delays and, then, I though situation was not improved. For example, since this year started, I have only seen 8 GLSAs filled: http://www.gentoo.org/security/en/glsa/ Er, we're 18 days in… You shouldn't look at this purely by the numbers, you should see that we have now again a steady stream of advisories going not. No gaps like from 2013-01 to 2013-07. That is largely the effort of the recently-joined members. Then, I thought something was still wrong as that rate didn't seem enough to me for handling upcoming security issues and the really old ones. Also, if you that 8 GLSAs, you will see the only one that has been done in a fast way is the ntp one, the other 7 took months (or years) to be handled. So you observed correctly there's still plenty of delays. There are three parts to an advisory that take time: - Drafting: Collecting information, linking references, getting package versions done right (slots are a huge pain still). - Reviewing: Our current process asks for two independent positive reviews from other team members before an advisory can be sent. - Sending: The original author gets a .txt to email and have to check in the .xml to CVS. Going through these three steps requires at least three people, and the (group of) people whose action is required shifts twice. That overall process is spot #1 we are planning to improve. The current plan contains requiring only one review and the reviewer sends the advisory directly. So we go from author - reviewer 1 - reviewer 2 - author to just author - reviewer. Concerning the single steps here are other measures: - Drafting: Implement a new GLSA format to * reduce the amount of editorial text written by us * support slots (makes specifying vulnerable ranges in slotted package much easier) * (cleanup old stuff no longer needed) - Reviewing: Reduced editorial text means less to review. - Sending: We want to improve our tooling to automatically send advisories and push them to a git repository. The new GLSA format was up for review on -security last week. Next up will be getting it specified formally, implemented in our tooling, glsa-check and a new security.g.o frontend. [1] Then, we can adopt the new workflow. Then, instead of blaming on how should I have asked for clarification on this (well, looks like the main topic here is that I have asked about this in ML instead of the real problem :O), I think you should focus on explaining how are you fixing this problem. Your original email didn't reflect actual interest in the details. Now that we've established you do care, I hope my explanations helped you out there. I have been long time wondering about this because: 1. I usually get lots of bugs from alias I am a member whose we go fast bumping, calling for stabilization and dropping vulnerable versions and, the, the bugs get stalled. 2. Once of the machines I maintain would benefit from being able to use glsacheck to only update vulnerable packages as not always have enough time for updating the full world [1] Lots of code to be written here. .py+.rb, help wanted! -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure
Re: [gentoo-dev] Local Gentoo User Group community support
On 15.11.2013 20:12, yac wrote: Hi What does Gentoo Linux provide for $SUBJ? I know there are mailing lists like gentoo-user-lang. Is there anything else? -project is where you wanted to post this --- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Moving project pages to wiki.gentoo.org
On 25.09.2013 20:38, Mike Gilbert wrote: Apologies if this has been covered elsewhere, but how are we dealing with herds.xml? Many herds are compiled from the project pages using maintainingproject element. How does that work if the project pages are going away? The /proj/en/foo entries will be replaced by Project:Foo, or just Foo. Until now, the (raw) herds.xml served didn't expand maintainingproject, I'd like to change that as querying member information isn't as easy as getting /proj/en/foo?passthru=1 anymore. At any rate, I have noted this as a to-do item for when the migration nears completion. -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [Bug 483274] app-text/poppler-0.22.5 Please stabilize
On 16.09.2013 15:19, Rich Freeman wrote: Additionally, can anybody who knows more about bugzilla comment on how easy it would be to have some way to mark modifications as trivial, and take this into account in the bugspam? Either make it configurable as to whether users get trivial bugspam (ideally), or at least stick something in the headers that can be filtered on. https://bugs.gentoo.org/userprefs.cgi?tab=email allows pretty fine-grained control over what email you receive. -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [Bug 483274] app-text/poppler-0.22.5 Please stabilize
On 16.09.2013 15:47, Dirkjan Ochtman wrote: On Mon, Sep 16, 2013 at 3:45 PM, Michael Palimaka kensing...@gentoo.org wrote: That is a useful tool, but many people get a lot of their bugmail through an alias. There's a trick where you can route all email from Bugzilla to the alias to /dev/null and watch the alias on Bugzilla, thereby applying your own email preferences. Alternatively, should there be a consensus amongst the members of a certain alias what email they would like to getg, we can change the settings for the alias user. Hat tip to Mike Gilbert. Cheers, Dirkjan -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] s/disk space/drive space
On 30.07.2013 13:50, Alexander Berntsen wrote: For future reference, I don't think you're using that right. You get to make statements for future reference if you actually have authority to tell people what to do. please use drive space rather than disk space. This includes in eclasses like check-reqs. 'disk space' is a perfectly valid term even if you have fancy solid state drives these days. It is an established term in technical documentation that everyone understands even if you don't physically use a 'disk'. Wikipedia lists 'disk space', not 'drive space' as do two English-* dictionaries I checked. Why should we be coining 'drive space'? -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [1/3] Automatic *XML-Wiki wiki.gentoo.org
On 10.07.2013 01:53, Alex Xu wrote:
(Delayed due to list servers being down)
On 08/07/13 06:48 PM, Alex Xu wrote:
On 08/07/13 04:02 PM, Sven Vermeulen wrote:
On Wed, Jun 26, 2013 at 03:54:47PM +0200, Alex Legler wrote:
I keep track of the stuff at [1], an example output can already be found at
[2].
[1] https://wiki.gentoo.org/wiki/User:SwifT/proj2wiki
[2] https://wiki.gentoo.org/wiki/User:SwifT/proj2wiki/test
It would appreciate some feedback - things that do not need to be covered
anymore or so (I know our wiki supports some stuff that shouldn't be
rendered anymore).
I don't really like the default MW table style here; it doesn't really
look... Gentoo, if you will. I hacked around the CSS a bit and I'd say
the new look works better. http://i.imgur.com/5eD7FGy.png
Oh god no. The days of these tables are numbered.
Which brings me to...
- Developer list: Moves to the sidebar. Not sure how to render that.
Maybe in a comment and people remove that once they have added all the
members?
- Subproject list: Moves to the sidebar as well. Same treatment as for
the developer list.
Another styling-related concern, the post-dev text is:
All developers can be reached by e-mail using '''nickn...@gentoo.org''' .
It should be:
All developers can be reached by e-mail using
codenickn...@gentoo.org/code.
The line should just be removed altogether.
Also, this output is not correct:
... join the mailing list at{{Mail|
gentoo-harde...@lists.gentoo.org}}.
There is a new line after Mail|. It should be:
... join the mailing list at {{Mail|gentoo-harde...@lists.gentoo.org}}.
c should translate to code, not '''.
inherit output, while a good start, is clearly incorrect. (Ctrl-F
SELinux subproject resources)
Other than that, there don't seem to be any major issues. Excellent work!
--
Alex Legler a...@gentoo.org
Gentoo Security/Ruby/Infrastructure
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [1/3] Automatic *XML-Wiki wiki.gentoo.org
On 16.06.2013 02:28, Robin H. Johnson wrote:
From the infra perspective, I would like to add that I support this
move, I just have a few concerns on the conversion, one of which is
dealt with here.
I've committed my draft XSL to the gentoo/xml/htdocs/xsl location, named
guidexml2wiki.xsl. It still requires some updates that I'll work on soon
(such as handling internal links) as I'll be using it more and more for the
guides on gentoo.org/doc/en to move to the wiki as well.
ProjectXML generates towards GuideXML, so should be usable chained.
It would be nice to move the foundation/ content to the Wiki as well I
think.
Sure. It doesn't count as a project I guess, so you would move into
Foundation:.* ?
PS An ebuild for a single stylesheet seems like overkill to me, but i've
been proven incorrect in the past...
I think it would help a lot of the devs that are put off by the concept
of XML/XSLT. Just give them a little wrapper script to generate wiki
output.
One of my large concerns was how to handle some of the tag conversion.
We have a lot of custom tags, plus some interesting behavior in some
tags.
Sven's XSL makes a very good start, but somebody needs to put in some
TLC for the following tags in conversion, and/or can we have it emit
something useful so we know when we hit a tag that's missing in the
XSLT.
Here's my list of tags found in proj/ that aren't in the XSLT so far:
(the / is just because I collapsed the tag of any attributes, there
probably
needs to be an audit of how the XSL handles attributes).
179 body/
ignore, needed by guidexml
145 i/
i.*?/i - ''\1''
74 mail/ (optional attribute link)
This functionality is replaced by the {{Mail}} template.
Usage:
* {{Mail|a3li}} - a href=mailto:a...@gentoo.org;Alex Legler/a
* {{Mail|a3li|foo}} - a href=mailto@a...@gentoo.orgfoo/a
* {{Mail|a3li@g.o}} - a href=mailto:a3li@g.o;a3li@g.o/a
* {{Mail|a3li@g.o|foo}} - a href=mailto:a3li@g.o;foo/a
27 dev/
Project members will have to be recreated using the form.
25 br/
keep br /
18 license/
Discard, everything is the same CC license, the old 2.x version allows
upgrade to the 3.0 we use.
15 extrachapter/ (optional attribute position)
Discard, GuideXML specific.
9 resource/ (attribute resource)
These resource things could just become a list:
* foo
* bar
* baz
7 project/
7 name/
7 longname/
7 longdescription/
7 description/
6 subproject/ (attribute ref)
Dump information, contents need to be recreated using the form as well.
Longdescription should 'just' be the first paragraph of the wiki page.
4 goals/
2 summary/
2 requirements/
Does anyone actually use the goals feature? imo, discard.
2 recruitment/
2 keyword/
2 job/
2 details/
2 contact/
Discard. I have moved staffing needs already.
1 var/
1 subtitle/
1 stmt/
1 ident/
1 const/
We have proper syntax hilighting in the wiki. Discard?
1 extraproject/ (attribute name)
Shouldn't these be proper projects?
--
Alex Legler a...@gentoo.org
Gentoo Security/Ruby/Infrastructure
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo Hangouts
On 24.06.2013 08:31, Alexander Berntsen wrote: I realise that by Gentoo is and will remain Free Software[0], what is meant is the distribution and the source code. However, I think it would be a bad example to use proprietary software for development or communication. So we shouldn't be present on Google+ at all? [0] http://www.gentoo.org/main/en/contract.xml -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo Hangouts
On 24.06.2013 12:01, Chí-Thanh Christopher Nguyễn wrote: Alex Legler schrieb: On 24.06.2013 08:31, Alexander Berntsen wrote: I realise that by Gentoo is and will remain Free Software[0], what is meant is the distribution and the source code. However, I think it would be a bad example to use proprietary software for development or communication. So we shouldn't be present on Google+ at all? Last I checked, …and I check every day! you can use Google+ with a web browser. For hangouts, you need to install the proprietary google-talkplugin (I don't think a usable free replacement exists yet). Sure, but the (web-accessible) platform itself is proprietary as well. I don't see it as much of an issue to use this channel—as long as it isn't the only one we offer. Best regards, Chí-Thanh Christopher Nguyễn -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [23]/3 API files
On 22.06.2013 11:20, Markos Chandras wrote: On 16 June 2013 02:21, Robin H. Johnson robb...@gentoo.org wrote: Special pages and contents http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml Since I am the one generating this one, I don't think it makes sense to move it into a git repo as it is. The script is actually pretty simple. The text from chapter 1 is always the same (ie cat header maintainer-needed.xml) and then I generate the list of packages using the portageq --maintainer-email=maintainer-nee...@gentoo.org -n output. So, in theory other developers never have to touch it unless they want to change the text of chapter 1. This rarely happens (I never changed it since day 0). But if you want to put it on a git repo, I need to rewrite it a bit because it is not pretty as it is. That sounds like a page to have on qa-reports.g.o. When you're happy with the script quality, let infra know and we'll add it there. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 16.06.2013 06:01, Paweł Hajdan, Jr. wrote: On 6/9/13 7:22 AM, Alex Legler wrote: I'd appreciate some input on below plan to move project pages to the Wiki: Alex, thanks for working on this! Some feedback: 1. How will the project pages be protected against unwanted edits? I think it's valuable to have some official pages where you know only Gentoo devs can edit them. The Project: namespace is restricted to only allow users in the developer group to edit. 2. How will the staffing needs page be updated after dropping gorg? You create a subpage for each staffing need, filling in information using a form. Semantic magic aggregates these, and you'll get a template to include for your project page to list the ones for your project specifically. 3. How secure is the wiki? Do we have regular backups and security updates procedures in place? I know you're member of the security team and infra team is doing its job well, but I just wanted to check. Dynamic web applications arguably have bigger attack surface than effectively a bunch of static files only editable after you gain server access. It's part of the usual infra backup, and I follow upstream release announcements and update accordingly. Paweł -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [23]/3 API files
On 16.06.2013 03:21, Robin H. Johnson wrote: Special pages and contents -- herds.xml, repositories.xml, etc.: As these are intended for other applications to use, these should go to a new site, possibly api.gentoo.org, initially fed from a git repository. This site should get backed by SSL. Here's a partial list of the ones I know about: http://www.gentoo.org/proj/en/overlays/repositories.xml http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml http://www.gentoo.org/main/en/mirrors3.xml Both of these are broken I think: http://www.gentoo.org/proj/en/perl/outdated-cpan-packages.xml http://www.gentoo.org/proj/en/perl/outdated-cpan-packages-perl-experimental.xml - Do you know of more? http://www.gentoo.org/proj/en/metastructure/herds/herds.xml - How can we better encourage these to move to an API site? Not sure what you mean with that. - Some of these are meant for human consumption, others are meant for tool consumption, should be differentiate? Human consumption - qa-reports.g.o Image resources: These can be uploaded to the Wiki. How can we ensure later that the media files don't get deleted? Deletion is restricted to administrators, mediawiki also keeps old versions around in case someone reuploads a file. To prevent even that, we can restrict editing certain assets to developers. Other files and downloads: Until proper project file hosting is implemented, again a simple git-backed static site, possibly projects.gentoo.org. Please don't put lots of binary files in Git. How do we expose that site to developers then? Akin to the mirroring system on d.g.o? -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [23]/3 API files
On 16.06.2013 21:44, Robin H. Johnson wrote: […] - How can we better encourage these to move to an API site? Not sure what you mean with that. It needs to be really easy for any developer to throw up a new data source w/ scripts onto the API site. Even qa-reports is somewhat stalled, and doesn't have good visibility, because it's not that easy for any dev to add something new to it. Currently, it's files in CVS, soon to be files in a Git. That's at least the same reachability as before. I think solving this problem is a separate task. Image resources: These can be uploaded to the Wiki. How can we ensure later that the media files don't get deleted? Deletion is restricted to administrators, mediawiki also keeps old versions around in case someone reuploads a file. To prevent even that, we can restrict editing certain assets to developers. See my other comment about git-mediawiki maybe, that would satisfy my needs, just having old versions of the images around as needed (not admin-deletable). Um, got a link for that extension? I didn't clarify, the Wiki can be configured to keep a revision even if someone deletes a file. Other files and downloads: Until proper project file hosting is implemented, again a simple git-backed static site, possibly projects.gentoo.org. Please don't put lots of binary files in Git. How do we expose that site to developers then? Akin to the mirroring system on d.g.o? I need to dust off the project hosting proposal, because there are a lot of files that need to move to it (like all the elections PR materials). …or that. -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 11.06.2013 13:05, Theo Chatzimichos wrote: On Tuesday, June 11, 2013 12:20:20 Sven Vermeulen wrote: Jason A. Donenfeld zx...@gentoo.org wrote: On Sun, Jun 9, 2013 at 4:22 PM, Alex Legler a...@gentoo.org wrote: - Projects: Use a GuideXML-to-Wikisyntax conversion tool to create an initial wiki version of the document What is the current status of such a tool? It is a script (xslt) that can be used with xsltproc to convert large chunks into wiki style. It isn't perfect though thus still requires manual review, but it is doable. I *think* I committed one to the repo a while ago. If not, I'll do so soon (I have one in my own repo just for this purpose). How about an ebuild please? Optional. I intend to expose this as a web site/service. -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 10.06.2013 14:36, Sergey Popov wrote: 09.06.2013 18:22, Alex Legler пишет: I'd appreciate some input on below plan to move project pages to the Wiki: Motivation -- The main motivation is to reduce the contents on the main website, allowing for an easier makeover. Also, the Wiki exposes the contents and an editing capability to more people, allowing for better collaboration. Finally, this is an opportunity for projects to go through the contents in their project spaces and update/remove outdated contents as well Gentoo as a whole to remove orphaned projects. Err, i do not want to say that wiki is not suite for this purpose, but what's wrong with current situation? Is there something wrong with gorg? The software is unmaintained, and the website template is next to unmaintainable. I could go on a bit more about this, but I think these two points *alone* justify moving away from it. Well, it is not always clear how to use some of it's features, but apart of that, why we should migrate to wiki? Just to clear orphaned project pages? No, I described multiple points. Again: - Less contents on www.g.o - we can much more easily relaunch it - Users can more easily contribute to project documentation - Update/purge project documentation - Remove orphaned projects Why we can not just have official project pages, maintained as usual through gorg and additional info in wiki(if it is needed, for example, like we do on Gentoo Qt project page? In case it wasn't clear enough yet: This is step 1 of n to get rid of gorg and GuideXML for the website (read: not main docs) aspects of Gentoo. Running two project page venues increases maintenance instead of lowering it. I intend to have less work after this change, not more. Do you have any concerns beyond 'never change a running system'? -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
I'd appreciate some input on below plan to move project pages to the Wiki: Motivation -- The main motivation is to reduce the contents on the main website, allowing for an easier makeover. Also, the Wiki exposes the contents and an editing capability to more people, allowing for better collaboration. Finally, this is an opportunity for projects to go through the contents in their project spaces and update/remove outdated contents as well Gentoo as a whole to remove orphaned projects. Process --- - Infra: /proj/* in CVS becomes read-only - Projects: Go through documents, updating them or marking them to be discarded - Projects: Use a GuideXML-to-Wikisyntax conversion tool to create an initial wiki version of the document - Projects: Enter URL mapping information into a form - Infra: Redirect www.g.o/proj/* to the respective Wiki pages Before doing this with every project, I'd like to do a field trial with 2-4 projects. Timeframe - The process should not take longer than 4 weeks. Special pages and contents -- herds.xml, repositories.xml, etc.: As these are intended for other applications to use, these should go to a new site, possibly api.gentoo.org, initially fed from a git repository. This site should get backed by SSL. Image resources: These can be uploaded to the Wiki. Other files and downloads: Until proper project file hosting is implemented, again a simple git-backed static site, possibly projects.gentoo.org. Project main pages: Using Semantic MediaWiki, we can represent all the semantic information we had on the project pages, like members and subprojects, on the Wiki as well. (Do we need more information than we can currently express in the guidexml markup or can any be removed?) Project-created documentation: Projects should consider moving documentation pages they created into the main Wiki namespace, allowing users to improve the documents. -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 09.06.2013 17:44, Ulrich Mueller wrote: On Sun, 09 Jun 2013, Alex Legler wrote: I'd appreciate some input on below plan to move project pages to the Wiki: Some questions: - Do we need to update GLEP 39? It requires a project page in www.g.o/proj/en/ that is actively maintained. Yes, obviously. Thanks for pointing that out. - What is the namespace policy in the Wiki? IIUC, the project pages itself should go to [[Project:Myproject]] and any subpages should go to [[Project:Myproject/Whatever]]? But what are the rules for project documentation that should be editable by all users, i.e. project pages in the main namespace? As our current guideline [1] says: The title should be specific, short and unambiguous. Other than that, no restrictions. Alex Ulrich [1] http://wiki.gentoo.org/wiki/Gentoo_Wiki:Guidelines -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Moving project pages to wiki.gentoo.org
On 09.06.2013 17:57, Andreas K. Huettel wrote: I'd appreciate some input on below plan to move project pages to the Wiki: Last time I chatted with people about this, it was unclear how exactly translations would be handled on the wiki. Has that been discussed and resolved? As there was no disagreeing feedback, I launched the system we had in testing [1] today. The current process is described in [2], but could see minor changes as more and more translators went through it. Cheers, A [1] http://translatewiki.net/wiki/Technology [2] http://wiki.gentoo.org/wiki/Help:Translating -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] splashutils needs a maintainer
On 27.01.2013 23:06, Pacho Ramos wrote: With spock retirement, splashutils became orphan. The problem is that it has a lot of unresolved bugs for a long time: https://bugs.gentoo.org/buglist.cgi?quicksearch=splashutilslist_id=1521218 that would need someone with more knowledge about it to maintain it (as I don't have splash on my systems for years). Also looks like splashutils is no more developed, but I don't know if we have a proper replacement for it in gentoo (most distributions are moving to plymouth, but I haven't tried if it works ok on Gentoo) We have it, it works (or at least worked). Someone would need to implement it in genkernel initrds though as at the moment only dracut can handle it. In terms of package maintenance, I took the package from aidecoe when he dropped it to avoid it getting removed. People seem to have found issues in there now and it could use a bump. As I cannot boot my systems using dracut initrds right now, feel free to take the package (and the openrc plugin for it) and fix/bump/do whatever with it. Thanks for your help -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed
Am 2012-09-13 22:11, schrieb Rich Freeman: On Thu, Sep 13, 2012 at 3:57 PM, Pacho Ramos pa...@gentoo.org wrote: El jue, 13-09-2012 a las 15:48 +0200, Alex Legler escribió: Sorta OT but a general thing: I think you should CC teams you want to talk to and not only use the gentoo-systemd-flamewars^W^W-dev mailing list where these teams might only find your post by chance. I thought all developers were subscribed to gentoo-dev and would read it :| No. -dev is not mandatory and several people are explicitly not subscribed, others don't read it regularly. Given the low SNR this list currently has, that's not really a surprise. Maybe, maybe not, but this seems like the appropriate place to discuss it. Maybe -project instead. However, I don't think you need to CC 14 teams on an email just in case they don't read -dev. Debate it on -dev, and then announce the outcome on -announce if it is important enough. Don't be silly. This is not about 14 teams, it pertains mainly one team. CCing one alias is not too much to ask for, given people CC aliases all the time even for simpler things than this. Also, I'd like to be asked before *you* change things in *my* team's policy. (Think someone touching others' ebuilds, all hell would break loose) So: Discuss with the team (on -dev *if* they read it), then announce on -dev-announce. We read it fairly soon this time, but please don't expect everyone is actively filtering the traffic on this list for things that pertain to them. There are team aliases for a reason. Rich -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure
Re: [gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed
On 13.09.2012 09:29, Pacho Ramos wrote: […] OK, then, looks like the policy could be that, once all arches are done, maintainers cleanup ebuilds and unCC themselves, that way, if they are still getting mails from bug report is because they forgot to remove vulnerable versions and, if not, is because all their work was finished. Are you ok with this policy? A general note: The request makes one wonder a bit how much you actually care about your package if a few emails disturb you. Arches, Security, and users reporting issues are trying to help you get the package into a good shape. Now, I can understand the request for the sake of possibly less email, less bugs appearing in bugs I'm in CC on searches and such, especially when things on the security side take a bit longer. We have no problem with people removing themselves after a bit of time, after arches are done and vulnerable versions are removed, but I certainly won't encourage people to do that actively right away. The reasons for this are a) that unCC usually generates another email (hey, not just maintainers want as little email as possible) and b) sometimes things still come up that require maintainer attention (mostly users reporting issues). The Security team certainly won't unCC people as suggested before in the thread, and if there are packages where more issues happen post-unCC, we'd have to manually reCC maintainers every time. So you'd weigh up our time with a few bytes in your inbox. What we could agree on is clarifying that maintainers have to stay on CC until stabling is done and vulnerable versions are removed, they can, if they want, remove themselves after a bit of time after that, and that Security might ask them to stay on CC next time, should the package turn out to require their attention after stabling more often. @security: ack? Alex -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed
On 12.09.2012 19:59, Pacho Ramos wrote: Hello Currently, package maintainers are CCed to security bugs when their are needed. The problem is that, once maintainers add a fixed version and tell security team they are ok to get it stabilized, maintainers are kept CCed until bug is closed by security team. This usually means getting a lot of mail after some time when security team discuss if a GLSA should be filled or not, if security bot adds some comment... some of that comments are applied to really old bugs that need no action from maintainers. Maybe would be interesting to change the policy to unCC maintainers again when their action is no longer required. What do you think? Sorta OT but a general thing: I think you should CC teams you want to talk to and not only use the gentoo-systemd-flamewars^W^W-dev mailing list where these teams might only find your post by chance. Thanks for your thoughts -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] plymouth maintainer-needed
On Wednesday 18 April 2012 16:03:09 Amadeusz Żołnowski wrote: Hi, I no longer use plymouth and have no more will to work on it, but because I believe many users use this package it would be good if somebody take maintainership of it. I'll take it for now. Co-maintainers welcome. There's only one serious bug opened at this time and there's no much work with this package. I have also written some howto for users: http://dev.gentoo.org/~aidecoe/doc/en/plymouth.xml (Append .src to get the source.) You can move it anywhere you want. I guess this should go to the wiki. Plymouth has plugin I have written for OpenRC (see its openrc use flag) which is more proof-of-concept rather something to be used really seriously, therefore best would be to drop this plugin and support only systemd which is supported by upstream ootb. Works fine for me, so there's no point in dropping it in fear of systemd. -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] plymouth maintainer-needed
On Wednesday 18 April 2012 17:01:28 Amadeusz Żołnowski wrote: I guess this should go to the wiki. I was asked in the past to move howto from wiki to some more reliable place, because wiki used to be offline quite often. Has this been changed? If you move it, please just know me the address so I can redirect users from the old one. I didn't mean the community wiki, but our own one (wiki.gentoo.org). -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: Various horde packages
Up for removal in 4 weeks: # Alex Legler a...@gentoo.org (28 Nov 2010) # Not maintained, multiple security issues. # Use the split horde ebuilds instead. www-apps/horde-webmail www-apps/horde-groupware # Alex Legler a...@gentoo.org (28 Mar 2012) # Leftover packages from a packaging attempt of Horde-4 # These can be readded when someone picks the package up dev-php/Horde_ActiveSync dev-php/Horde_Alarm dev-php/Horde_Argv dev-php/Horde_Auth dev-php/Horde_Autoloader dev-php/Horde_Browser dev-php/Horde_Cache dev-php/Horde_Cli dev-php/Horde_Compress dev-php/Horde_Constraint dev-php/Horde_Controller dev-php/Horde_Core dev-php/Horde_Crypt dev-php/Horde_Data dev-php/Horde_DataTree dev-php/Horde_Date dev-php/Horde_Date_Parser dev-php/Horde_Db dev-php/Horde_Exception dev-php/Horde_Feed dev-php/Horde_Form dev-php/Horde_Group dev-php/Horde_History dev-php/Horde_Http dev-php/Horde_Icalendar dev-php/Horde_Image dev-php/Horde_Imap_Client dev-php/Horde_Imsp dev-php/Horde_Injector dev-php/Horde_Itip dev-php/Horde_Kolab_Format dev-php/Horde_Kolab_Server dev-php/Horde_Kolab_Session dev-php/Horde_Kolab_Storage dev-php/Horde_Ldap dev-php/Horde_Lock dev-php/Horde_Log dev-php/Horde_LoginTasks dev-php/Horde_Mail dev-php/Horde_Memcache dev-php/Horde_Mime dev-php/Horde_Mime_Viewer dev-php/Horde_Nls dev-php/Horde_Notification dev-php/Horde_Oauth dev-php/Horde_Pdf dev-php/Horde_Perms dev-php/Horde_Prefs dev-php/Horde_Rdo dev-php/Horde_Role dev-php/Horde_Routes dev-php/Horde_Rpc dev-php/Horde_Scribe dev-php/Horde_Secret dev-php/Horde_Serialize dev-php/Horde_Service_Facebook dev-php/Horde_Service_Twitter dev-php/Horde_SessionHandler dev-php/Horde_Share dev-php/Horde_SpellChecker dev-php/Horde_Sql dev-php/Horde_Stream_Filter dev-php/Horde_Stream_Wrapper dev-php/Horde_Support dev-php/Horde_SyncMl dev-php/Horde_Template dev-php/Horde_Test dev-php/Horde_Text_Diff dev-php/Horde_Text_Filter dev-php/Horde_Text_Filter_Csstidy dev-php/Horde_Text_Flowed dev-php/Horde_Thrift dev-php/Horde_Token dev-php/Horde_Translation dev-php/Horde_Tree dev-php/Horde_Url dev-php/Horde_Util dev-php/Horde_Vfs dev-php/Horde_View dev-php/Horde_Xml_Element dev-php/Horde_Xml_Wbxml dev-php/Horde_Yaml -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: PGP signature
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On Wednesday 31 August 2011 15:41:51 Corentin Chary wrote: Hi, some news about euscan (still available at http://euscan.iksaif.net) - New design (yay !) Glad you like it. Be sure to credit where you got it from, though. -- Alex Legler a...@gentoo.org Gentoo Security / Ruby signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Using Jabber for developer communication
On 4/10/11 1:00 PM, Dmitry Dzhus wrote: When will Gentoo switch over to glorious and progressive Jabber from outdated and obsolete IRC? After we've moved gentoo.org to myspace.com/gentoo. Happy trolling, Alex signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Using Jabber for developer communication
On 4/10/11 2:11 PM, Michał Górny wrote: On Sun, 10 Apr 2011 14:06:56 +0200 Alex Legler a...@gentoo.org wrote: On 4/10/11 1:00 PM, Dmitry Dzhus wrote: When will Gentoo switch over to glorious and progressive Jabber from outdated and obsolete IRC? After we've moved gentoo.org to myspace.com/gentoo. Myspace is passé. I think cool kids use facebook nowadays. You successfully missed the joke. (And please don't CC the senders when replying to the list) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: bugzilla cleanup: remove SECURITY keyword?
On 1/18/11 3:31 PM, Paweł Hajdan, Jr. wrote: Is it worthwhile to remove the SECURITY keyword from 79 bugs... It is not, we would have told you before if you had actually asked us. (hoping you get the hint) ...if you consider that (if everyone gets keyword-changes bugzilla mails, it's an Email Preference[2] configurable in bugzilla) 79 mails are sent to 11 + 63 + other CC'ed recipients? I wonder how many e-mails would be sent if we used the Change several bugs at once Bugzilla feature. My guess is just one e-mail. No, one email per bug. Maybe we can just update description of obsolete KEYWORDS with something like *** DEPRECATED *** don't use for new bugs. That should be easy and address most of my original point. Do that if it restores your inner peace, but leave the keyword in place on old bugs. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: bugzilla cleanup: remove SECURITY keyword?
On 1/18/11 4:06 PM, Torsten Veller wrote: * Alex Legler a...@gentoo.org: On 1/18/11 3:31 PM, Paweł Hajdan, Jr. wrote: Is it worthwhile to remove the SECURITY keyword from 79 bugs... It is not, we would have told you before if you had actually asked us. (hoping you get the hint) Paweł actually asked: What do you think about removing it? Why can't we (whoever it is) answer here? we: the team that sounds like that keyword he wants to remove. Security has a dedicated contact address, and I have made it clear in previous conversations that we like to be asked directly (and *not* on $random_mailinglist inbetween dozens of other things) before any things related to our responsibility happen. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [warning] the bug queue has 118 bugs
On 12/15/10 1:16 PM, Duncan wrote: Mike Frysinger posted on Tue, 14 Dec 2010 22:22:14 -0500 as excerpted: On Tuesday, December 14, 2010 20:54:45 Jeroen Roovers wrote: On Tue, 14 Dec 2010 14:00:02 +0200 (EET) Alex Alexander wrote: Our bug queue has 118 bugs! I am starting to wonder if this is helping. It looks like everyone now attempts to keep it 100 on a daily basis, but not to far 100, which means a lot of old, difficult, nasty bug reports are left unattended. Still, I got it down to about two dozen now. i think people will aim for whatever arbitrary limit is picked. so raising it to say 200 wont help either. Agreed. Which begs the question[1], why not take the opportunity to lower it? Just be careful: That will result in more emails, and in people getting annoyed by them putting filters on them, resulting in less people reading such emails, which will result in more open bugs, and more emails, repeat ad infinitum. Besides from that, I still don't really know why these things have to appear on our technical mailinglist. Alex signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC Bugzilla interaction guide for devs editbugs users
On Mon, 6 Sep 2010 10:39:59 +0200, Dirkjan Ochtman d...@gentoo.org wrote: [...] 2.2. Security bugs The developer should comment, but ONLY members of the security team should: - change whiteboard - add/remove arches - change bug status/reso The arches can still remove themselves when they've done whatever they needed to do, right? Of course. -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] FOSDEM 2011
On Thu, 26 Aug 2010 11:01:27 +0200, Markus Duft markus.d...@salomon.at wrote: booth registration is not yet open, i will have an eye on this too... (is there any interest in it anyway? who could come up with flyers, cds, etc.?) The Gentoo e.V. has printed flyers a year ago. There should be plenty left, especially in English. Talk to rbu, sping or hollow. Also, there's other stuff like T-Shirts, see https://www.gentoo-ev.org/wiki/Events for a few pictures. As for CDs, we've used the 10.1 LiveDVDs, simply burned to DVD-R, but with a nice printed label. You can expect to hand out at least 35 per day (we gave them to people for free after a short chat). -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Wiki(es) for Gentoo ?!
On Sat, 21 Aug 2010 02:37:49 +0200, Thilo Bangert bang...@gentoo.org wrote: Alex Legler a...@gentoo.org said: On Fri, 20 Aug 2010 23:01:42 +0200, Thilo Bangert bang...@gentoo.org wrote: Dear all, can somebody summarize what the status is for one or more wikies for gentoo - its users and/or its developers or whatever. I can see this: http://www.gentoo.org/proj/en/wiki/ There was a meeting (logs on this list) where the goals of the project were discussed and defined. Things like policies are still to be discussed. uh - hhm. cant seem to find it. will look further, when i'm fully awake tomorrow. You'll find it in Message-ID: aanlktimieyi0tgyprojdcjfr8rmlt_a_meul3wsqs...@mail.gmail.com from hwoarang: http://dev.gentoo.org/~hwoarang/files/meeting-1-log.txt would be great to link to stuff like this from the project page, though. done Infra has hardware ready and I have started building a set of git repos with the mediawiki sources for it. The testing wiki I host needs fixing because of a PHP update. I'll try to get to that this weekend. great - let me know. should be up now again: http://gentoowiki.a3li.li/index.php?title=Main_Page I'd like to know what and where someone interested in this could help. Thanks. Get the team to meet again and do the boring work (policies!). ok Or if you're into PHP talk to me about helping with the sources. do you have a TODO document laying around somewhere? i talk PHP from time to time. Not really, and on second thought laying out the initial structure is not something multiple people should/could work on. Why don't you join #gentoo-wiki, and add yourself to the wiki@ alias, I'll announce progress there. Alex -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Wiki(es) for Gentoo ?!
On Fri, 20 Aug 2010 23:01:42 +0200, Thilo Bangert bang...@gentoo.org wrote: Dear all, can somebody summarize what the status is for one or more wikies for gentoo - its users and/or its developers or whatever. I can see this: http://www.gentoo.org/proj/en/wiki/ There was a meeting (logs on this list) where the goals of the project were discussed and defined. Things like policies are still to be discussed. Infra has hardware ready and I have started building a set of git repos with the mediawiki sources for it. The testing wiki I host needs fixing because of a PHP update. I'll try to get to that this weekend. I'd like to know what and where someone interested in this could help. Thanks. Get the team to meet again and do the boring work (policies!). Or if you're into PHP talk to me about helping with the sources. Alex -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-apps/drupal: drupal-5.23.ebuild ChangeLog drupal-6.19.ebuild drupal-6.16.ebuild drupal-6.17.ebuild drupal-5.22.ebuild
On Tue, 17 Aug 2010 10:46:10 +0400, Peter Volkov p...@gentoo.org wrote: В Пнд, 16/08/2010 в 18:04 +, Alexey Shvetsov (alexxy) пишет: alexxy 10/08/16 18:04:52 Modified: ChangeLog Added:drupal-5.23.ebuild drupal-6.19.ebuild Removed: drupal-6.16.ebuild drupal-6.17.ebuild drupal-5.22.ebuild Log: [www-apps/drupal] Version bump Always reference bug number and mention people that spent time reporting problems in our bugzilla. Please, add bug # and attribution into ChangeLog. Also with version bump it's always good idea to keep previous version to allow re-installation of previous versions in the case of regressions. https://bugs.gentoo.org/show_bug.cgi?id=323399 That's rather https://bugs.gentoo.org/show_bug.cgi?id=332541 I agree that the bug # should be referenced, but as for removing the old versions, that's something we usually ask people to do after bumping packages with security issues to minimize the risk of people installing possibly vulnerable versions. -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-apps/drupal: drupal-5.23.ebuild ChangeLog drupal-6.19.ebuild drupal-6.16.ebuild drupal-6.17.ebuild drupal-5.22.ebuild
On Tue, 17 Aug 2010 16:11:42 +0400, Peter Volkov p...@gentoo.org wrote: В Втр, 17/08/2010 в 11:27 +0200, Alex Legler пишет: but as for removing the old versions, that's something we usually ask people to do after bumping packages with security issues to minimize the risk of people installing possibly vulnerable versions. I agree with removal but not immediately. Personally I already had issues with another web application: it worked in my installation, but people were unable to use it after security fix. In that case: Reopen the bug and inform us. Besides, you should only get issues when dealing with ~arch ebuilds as they're not tested. But that's what you get for using testing. *shrug* Since having vulnerable but working installation is better then fixed but broken, No offense, but that's just naive. I'd rather always kept old versions for some time. Use a local overlay then. Also it's not a big problem to have old versions in the tree since you have to specify version number explicitly to install them... You obviously haven't been in our support venues and seen what some people are able to do... -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Council Agenda 20100809 rev 01
On Fri, 06 Aug 2010 14:49:19 -0700, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: 1. The Gentoo Security team is severly understaffed, they have an entry on the Staffing Needs page, but no long-term improvement is visible over the last 6 months. The status visibility is low, and it's even hard to ask for tasks to help with. And you'd like the council to do what about that exactly? -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council 2010/2011 - Nominations are now open
On Tue, 15 Jun 2010 13:17:20 +0300, Markos Chandras hwoar...@gentoo.org wrote: *a3li Thank you, but I have to decline. My teams have lots of work right now, devoting more of my time to other things wouldn't be right. Alex signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council 2010/2011 - Nominations are now open
On Sat, 5 Jun 2010 02:00:02 +0200, Torsten Veller t...@gentoo.org wrote: Hello fellow developers and users. Nominations for the Gentoo Council 2010/2011 are now open for the next two weeks (until 23:59 UTC, 18/06/2010). Chainsaw, Fauli and sping please. -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Gentoo Wiki Project
On Mon, 5 Apr 2010 20:12:49 +0200, Ben de Groot yng...@gentoo.org wrote: After the mostly positive feedback on the recent wiki discussion, we have now gone ahead, formed a preliminary team consisting of both users and developers, and put up a project page [1]. All constructive feedback on this new project is welcome. We'd also like to invite any users and developers, who are willing to help to make this a success, to join us. At this point we are especially looking for people who can help with: - the initial setup and configuration of a MediaWiki instance idl0r and I are offering to arrange things with infra. As they are busy at the moment, I created a test wiki for us to test extensions and styling: http://gentoowiki.a3li.li/index.php?title=Main_Page I have installed a captcha extension, as well as the flagged revision extension. Contact me off-list for editor privileges for that. - the design of a custom Gentoo theme for MediaWiki (including graphics and CSS) In that aforementioned wiki, there is a hacked together purplified version of MediaWiki's new Vector theme. Maybe that's already enough. If not maybe someone wants to use it as a starting point (contact me off-list for details) Alex -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, 4 Apr 2010 00:31:52 -0700, Joshua Saddler
nightmo...@gentoo.org wrote:
No, he's definitely out to kill GuideXML. Just give him time.
At least for official documentation, that should not happen.
(That excludes non-doc parts of the website though imo. GuideXML is a
XML DSL designed for documentation, sadly it sucks for doing
websites.)
A wiki can fulfill several purposes for us:
[...]
However, a wiki *does* make it easier for everyone to jump right in
and edit stuff as ideas are passed around, rather than waiting for
someone to make changes to something in a devspace.
That's why we should want a wiki for general collaboration.
3. A place to host and maintain our existing documentation
[which is currently in GuideXML]
Entirely unnecessary duplication of effort. To quote the forum mods,
don't cross-post . . . and especially don't do it if you'll be
violating a doc license somewhere. It's one of the reasons why we
don't use existing unofficial wiki content in our docs. I and the GDP
have written about that ad nauseum over the years; just search the
list archives.
ack. It should /not/ be a goal of the Wiki to maintain official docs.
[...]
Show me a wiki that produces such beautiful code samples (with
titles).
[...]
. . . or a wiki that makes it super-easy to add all sorts of
additional in-line formatting to regular paragraphs, for example all
the blue highlighting for code used throughout
http://www.gentoo.org/doc/en/xml-guide.xml, or the monospace font
used for filesystem paths.
Let's be honest: Such things can be arranged. Most Wikis have a {{foo}}
- ttfoo/tt syntax already built in.
Show me a wiki that makes it easy to create tables, for example,
compare RadeonProgram from the x.org wiki:
http://www.x.org/wiki/RadeonProgram?action=edit
||-2 style=text-align: center; background-color: #66
'''Native''' ||style=text-align: center; background-color:
#66 '''R100''' ||style=text-align: center; background-color:
#66 '''R200''' ||style=text-align: center; background-color:
#66 '''R300''' ||style=text-align: center; background-color:
#66 '''R400''' ||style=text-align: center; background-color:
#66 '''RS690''' ||style=text-align: center; background-color:
#66 '''R500''' ||style=text-align: center; background-color:
#66 '''R600''' ||style=text-align: center; background-color:
#66 '''R700''' ||
. . . that's one line of cells. One. Ugly. Compare it to:
http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap5_pre1
table
tr
thFoo/th
thBar/th
/tr
tr
tiThis is an example for indentation/ti
timore stuff/ti
/tr
/table
Meep. That's an unfair one.
The guidexml snippet does not contain any styling. (Oh wait, I forgot,
it doesn't even support styling. [another reason why it sucks for
websites])
[...]
I ain't out to stop ya'll from using a wiki. I do agree that they
have some advantages. However, I will point out how limited wikis
are. They're not a magic bullet that will solve all our problems.
Again: Official docs should not be considered as Wiki material indeed.
Of course if someone feels like experimenting with such things in the
Wiki, feel free to. If the experiment should be really successful, the
GDP might reconsider.
But it's still the GDP's sandbox and as long as they're playing in it,
don't take away their toys.
Let's work *together* towards a better Gentoo, so let's consider the
official docs off-limits for the Wiki effort (at least for now) as
there are valid reasons against such a thing.
Alex
--
Alex Legler | Gentoo Security / Ruby
a...@gentoo.org | a...@jabber.ccc.de
signature.asc
Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, 4 Apr 2010 10:48:52 +0200, Antoni Grzymala awa...@chopin.edu.pl wrote: Has anyone considered the immensely powerful twiki? The Webs concept of TWiki is interesting and the table editing nifty, but we would need to assess if it matches our goals. I somehow fear that it outreaches our aims a bit. -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On Sun, 04 Apr 2010 01:37:03 +0200, Sebastian Pipping sp...@gentoo.org wrote: [...] 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) We need moderators, that is clear. If they check the content for correctness and remove spam they might just as well click one more checkbox to mark a stable revision. - New bottlenecks That's sorta point #1 rephrased. 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? In MediaWiki, that'd be the nil namespace for 'registered', i.e. http://wiki.gentoo.org/wiki/25WaysToBreakYourMachine and $whatever for 'devs': http://wiki.gentoo.org/wiki/Devs:25WaysToBreakYourMachine or http://wiki.gentoo.org/wiki/Devwiki:25WaysToBreakYourMachine For MoinMoin, I'd suggest what they call a wikicluster. users: http://wiki.gentoo.org/gentoowiki/25WaysToBreakYourMachine devs: http://wiki.gentoo.org/devwiki/25WaysToBreakYourMachine I expect that to be - easy to implement For both, yes. - 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? ! -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
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 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] [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] [rfc] layman storage location (again)
On Fri, 15 Jan 2010 20:36:20 +0100, Sebastian Pipping sp...@gentoo.org wrote: Would /var/lib/layman do well? +1 -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/bip: metadata.xml ChangeLog bip-0.8.4.ebuild bip-0.8.1.ebuild
On Tue, 5 Jan 2010 12:17:39 +0100, Christian Faulhammer fa...@gentoo.org wrote: Hi, Alex Legler (a3li) a...@gentoo.org: a3li10/01/05 10:30:43 Modified: metadata.xml ChangeLog Added:bip-0.8.4.ebuild Removed: bip-0.8.1.ebuild Log: Version bump, add 'noctcp' option to disable automatic CTCP VERSION replies. Remove old version (Portage version: 2.2_rc59/cvs/Linux x86_64) [...] IUSE=debug noctcp ssl vim-syntax oidentd Please avoid no* USE flags, they are bad behaviour and will earn you a spanking. Use USE flag defaults if you want to activate it by default. I don't think the implications regarding noblah USE flags as stated in the devmanual apply to this case. There is no change in dependencies with that flag, so no problem for any arch teams. Also, I like the semantics of noctcp better. It's not just about enabling or disabling the CTCP stuff for flexibility's sake, it's about *specifically disabling* it avoid getting hit by morons sending floodbots to Freenode (or $any_irc_network). -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Why do packages which will not build remain in the distribution list?
On Wed, 30 Dec 2009 06:58:48 -0500, Richard Freeman ri...@gentoo.org wrote: [...] So a build error might not reflect a problem with the package you're trying to build. This is the case here. Some packages install broken pkg-config files (missing a Name: field) which will cause pkg-config --list-all to fail when encountering such a package. That in turn also makes the Ruby pkg-config library fail which is used in the configure step. We already have filed some bugs against these broken packages. Now we have to wait until all are fixed, or find a way to make pkg-config more resistant to such errors -- both are outside of the Ruby team's realm. Alex -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
[gentoo-dev] Last rite: dev-ruby/{nitro,og,glue,gen}
# Alex Legler a...@gentoo.org (30 Nov 2009) # Dead upstream, fetch issues with gemcutter. # Masking for removal in 30 days. dev-ruby/nitro dev-ruby/glue dev-ruby/gen dev-ruby/og -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Add RUBY_TARGETS to USE_EXPAND
On Tue, 6 Oct 2009 15:28:19 +0200, Alex Legler a...@gentoo.org wrote: I would like to propose the addition of a new USE_EXPAND variable. I have just commited the changes. -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
[gentoo-dev] RFC: Add RUBY_TARGETS to USE_EXPAND
Hey, I would like to propose the addition of a new USE_EXPAND variable. The Ruby team is currently working on a new version of ruby.eclass with proper support for packages installed for multiple versions of ruby. RUBY_TARGETS contains a list of ruby implementations and versions to install a package for, like this: [ebuild U ] dev-ruby/actionpack-2.3.2-r1 [2.3.2] USE=-doc -test% RUBY_TARGETS=ruby18* ruby19* -jruby% 746 kB [0=1] In that example, actionpack would install for Ruby 1.8 and 1.9. USE dependencies are then used to ensure all dependencies are built at least for 1.8 and 1.9 as well. Any comments or questions? Thanks, Alex signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Add RUBY_TARGETS to USE_EXPAND
On Tue, 6 Oct 2009 22:19:25 +0200, Christian Faulhammer fa...@gentoo.org wrote: Hi, Alex Legler a...@gentoo.org: RUBY_TARGETS contains a list of ruby implementations and versions to install a package for, like this: Python has to do the same for 2.x and 3 versions...wouldn't it be nice to have the same solution for both languages? It might be nice, /eventually/. As far as I can see, the proposed Python solution is just a concept, where we already have near-beta eclasses that we *really* want to deploy this year as they block the unmasking of Ruby 1.9. Additionally, there are some really nasty things about the current ruby.eclass (prepall override) and incompatibilities with RubyGems that should be resolved rather sooner than later. V-Li A3-Li signature.asc Description: PGP signature
Re: [gentoo-dev] horde and friends
On Mon, 21 Sep 2009 18:06:51 +0200, Benny Pedersen m...@junc.org wrote: [...] problem as i see it, is that we have multiple horde ebuilds, but it would make more sense to have one horde ebuild with more use flags ? Have you seen horde-webmail and horde-groupware? They include horde + several apps. Alex signature.asc Description: PGP signature
Re: [gentoo-dev] Stabilization of Python 3.1
On Sat, 19 Sep 2009 18:48:27 +0200, Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: Stabilization of Python 3.1.* will be requested at the beginning of november. There was a suggestion to create a news item which would inform users that temporarily they shouldn't switch to Python 3 as their main interpreter. What is the point of stabilizing it if users shouldn't use it as main interpreter? Just leave it in ~arch until it can be safely used. Alex signature.asc Description: PGP signature
Re: [gentoo-dev] Stabilization of Python 3.1
On Sat, 19 Sep 2009 19:09:38 +0200, Dirkjan Ochtman d...@gentoo.org wrote: On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote: What is the point of stabilizing it if users shouldn't use it as main interpreter? Just leave it in ~arch until it can be safely used. Making it easily available so that people can port stuff, so that the entire world may be able to use it as their main interpreter sooner? Don't you think that ~arch makes it easily available enough for people who *want* to port stuff? If I run stable Gentoo, I'm interested in a /stable/ system(tm) and not the latest Python version that people are still fiddling with. Especially since the Gentoo core system extensively uses Python. By the way, does Portage work with Python 3 yet? Seriously, it's out there, there's no reason to keep it from stable. Just prevent people from making python invoke 3.x and everything will be fine. Yeah, right, let's install it on all those stable machines, but then not use it. Way to go! Alex signature.asc Description: PGP signature
Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future
On Sun, 13 Sep 2009 16:25:19 -0500, Dale rdalek1...@gmail.com wrote: Where are these referrer logs? I don't recall ever doing one of those. They are in the web server logs. Apache includes them in the combined log format, or you can add them in a custom log format. So cooperation with Infra is required for this sort of analysis. Hasn't it been said before that Gentoo polls are pretty difficult to do and not very accurate? I fail to see the difficulty of both creating and filling out a survey on a forums post. Also, accuracy is always an issue when doing online surveys as people can submit it multiple times, and there's always the kids that just click something out of boredom. Don't think that problem is specific to Gentoo polls. Alex signature.asc Description: PGP signature
Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future
On Sun, 13 Sep 2009 17:08:38 -0500, Dale rdalek1...@gmail.com wrote: As has been said before, a lot of people don't go to the forums to see the poll. I only go to the forums to search if I have a problem before posting to the list. There may have been a dozen polls on the forums and I would have no idea they happened. That might be /your personal/ behavior. Of course, the same could be said about doing a poll on the mailing lists as well. Some Gentoo users that use the forums may not even know the mailing lists exists. Do the poll in the Forums. Advertise it on planet, some MLs, maybe the g.o front page, and on IRC. That way we reach the users that don't go to the forums, but are on IRC, and the folks that are on the forums but don't know of the MLs and vice-versa. Of course there'll be still people that don't know anything about the thing, but *shrug*. Those who care, know. And those who don't care, don't need to know, we have made our effort to reach people. I'm not sure any poll could really be accurate no matter which means is used. Maybe that is something we just need to live with. Guess all the other people who do Internet polls do. Besides, what can we lose? I don't think Sebastian would mind preparing and posting the survey. A little more community participation and a little less time spent talking instead of doing would do us good. Alex signature.asc Description: PGP signature
[gentoo-dev] Last rites: www-apps/diaria
Last upstream release was January 15, 2004, fails to install correctly in multi-ruby environments, doesn't even start without spitting a stacktrace. Due for removal in 30 days. Alex signature.asc Description: PGP signature
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On So, 2009-05-24 at 20:04 +0200, lx...@sabayonlinux.org wrote: [...] app-admin/equo (sabayon overlay -- Entropy Framework client) supports the postfix @repository to let users force the installation of a package from a specific repository. @ is used by Portage for sets. Paludis has been using ::repo for repo dependencies for years. Why not go with the established syntax? I wrote postfix not prefix. Sets use @ prefix. Your @ is still a prefix for the repository name. For usability's sake, please don't do this. I can imagine users getting confused over the different meanings of the @ sign. I do not want to trigger a discussion like the one PHP had when choosing namespace separators, but we got the :: established in Paludis and Paludis is used by way more Gentoo people than equo. So it only seems logical to me to use the wider-known and at the same time ambiguity-free operator. Alex signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: Ruby 1.8 with Oniguruma patches, ruby-config
# Alex Legler a...@gentoo.org (15 May 2009) # Masked for removal wrt bug #251833. Due for removal in 30 days. # Use app-admin/eselect-ruby instead. dev-ruby/ruby-config =dev-lang/ruby-1.8.6_p114 Ruby _p114 is the last Ruby with Oniguruma patches, however there are numerous security issues. Ruby 1.9.1 will contain Oniguruma again, people needing it in 1.8 can use a gem [1]. ruby-config is superseded by eselect-ruby. Cheers, Alex [1] http://oniguruma.rubyforge.org/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs
On Mo, 2009-03-23 at 11:26 -0100, Jorge Manuel B. S. Vicetto wrote: [...] Ali Polatel (hawking) [...] net-irc/bip Shamelessly stole that one. Gracias, Alex signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: gems.eclass review
On Fr, 2009-03-06 at 21:03 -0600, Ryan Hill wrote:
In the case that USE_RUBY is set to something funky, it never gets handled.
The eclass
basically just does nothing. This might be what you want, but if not, how
about something
like:
Actually, this is what we want. ;)
I noticed after I sent the eclass for review, that USE_RUBY=any should
not be used anymore. So I added a deprecation notice and will get rid of
it in a month or so.
+ dodir ${GEMSDIR}
|| die
Added the two die's, thanks.
I also added eclass-manpages-style documentation and empty EAPI-2
functions to make pva happy. :p
I am going to wait another couple of days before comitting if anyone
should have more comments. Updated the old URLs with the new changes:
http://dev.gentoo.org/~a3li/ruby/gems.eclass.txt
http://dev.gentoo.org/~a3li/ruby/gems.eclass.diff
Thanks,
Alex
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] gems.eclass review
Hey, we have some changes to be made in gems.eclass for Ruby 1.9.1. Basically this introduces the possibility to install gems for multiple versions of Ruby. If anyone feels like reviewing, please review the following changes: ;) http://dev.gentoo.org/~a3li/ruby/gems.eclass.txt Diff against the current version in the tree: http://dev.gentoo.org/~a3li/ruby/gems.eclass.diff Regards, Alex signature.asc Description: This is a digitally signed message part
