Merge branch 'master' into stoa

Larissa Reis
2 parents 7270935f b5ecb6a4
Showing 11 changed files with 167 additions and 10 deletions Show diff stats
AUTHORS.md
DEVELOPMENT.md
app/helpers/content_viewer_helper.rb
config/noosfero.yml.dist
debian/changelog
debian/noosfero.yml
lib/noosfero/version.rb
lib/tasks/release.rake
script/noosfero-plugins
test/unit/content_viewer_helper_test.rb
util/debian-install/install
@@ -40,6 +40,7 @@ Alessandro Palmeira + João M. M. Silva &lt;alessandro.palmeira@gmail.com&gt;
 Alessandro Palmeira + Paulo Meirelles <alessandro.palmeira@gmail.com>
 Alessandro Palmeira + Paulo Meirelles + João M. M. da Silva <alessandro.palmeira@gmail.com>
 Alessandro Palmeira + Rafael Manzo <alessandro.palmeira@gmail.com>
+analosnak <analosnak@gmail.com>
 Ana Losnak <analosnak@gmail.com>
 Andre Bernardes <andrebsguedes@gmail.com>
 Antonio Terceiro + Carlos Morais <terceiro@colivre.coop.br>
@@ -81,7 +82,6 @@ Carlos Morais + Diego Araújo &lt;diegoamc90@gmail.com&gt;
 Carlos Morais + Eduardo Morais <carlos88morais@gmail.com>
 Carlos Morais + Paulo Meirelles <carlos88morais@gmail.com>
 Carlos Morais + Pedro Leal <carlos88morais@gmail.com>
-Daniela Feitosa <dani@dohko.(none)>
 Daniel Alves + Diego Araújo <danpaulalves@gmail.com>
 Daniel Alves + Diego Araújo <diegoamc90@gmail.com>
 Daniel Alves + Diego Araújo + Guilherme Rojas <danpaulalves@gmail.com>
@@ -119,7 +119,6 @@ Diego Araújo + Renan Teruo &lt;diegoamc90@gmail.com&gt;
 Diego Araujo + Rodrigo Souto + Rafael Manzo <rr.manzo@gmail.com>
 Diego + Jefferson <diegoamc90@gmail.com>
 Diego Martinez <diegoamc90@gmail.com>
-Diego Martinez <diego@diego-K55A.(none)>
 Diego + Renan <renanteruoc@gmail.com>
 Eduardo Tourinho Edington <eduardo.edington@serpro.gov.br>
 Evandro Jr <evandrojr@gmail.com>
@@ -195,6 +194,7 @@ Luis David Aguilar Carlos &lt;ludwig9003@gmail.com&gt;
 Luiz Fernando de Freitas Matos <luiz@luizff.matos@gmail.com>
 Marcos Ramos <ms.ramos@outlook.com>
 Martín Olivera <molivera@solar.org.ar>
+Michal Čihař <michal@cihar.com>
 Moises Machado <moises@colivre.coop.br>
 Naíla Alves <naila@colivre.coop.br>
 Nanda Lopes <nanda.listas+psl@gmail.com>
@@ -221,6 +221,7 @@ Rafael Reggiani Manzo + João M. M. da Silva &lt;rr.manzo@gmail.com&gt;
 Rafael Reggiani Manzo <rr.manzo@gmail.com>
 Raphaël Rousseau <raph@r4f.org>
 Raquel Lira <raquel.lira@gmail.com>
+Raquel <rcordioli@gmail.com>
 Renan Teruo + Caio Salgado <renanteruoc@gmail.com>
 Renan Teruoc + Diego Araujo <renanteruoc@gmail.com>
 Renan Teruo + Diego Araujo <renanteruoc@gmail.com>
@@ -228,13 +229,13 @@ Renan Teruo + Diego Araújo &lt;renanteruoc@gmail.com&gt;
 Renan Teruo + Paulo Meirelles <renanteruoc@gmail.com>
 Renan Teruo + Rafael Manzo <renanteruoc@gmail.com>
 Rodrigo Souto + Ana Losnak + Daniel Bucher + Caio Almeida + Leandro Nunes + Daniela Feitosa + Mariel Zasso <noosfero-br@listas.softwarelivre.org>
-Rodrigo Souto <diguliu@gmail.com>
 Rodrigo Souto <rodrigo@colivre.coop.br>
 Ronny Kursawe <kursawe.ronny@googlemail.com>
 root <root@debian.sdr.serpro>
 Samuel R. C. Vale <srcvale@holoscopio.com>
 Tallys Martins <tallysmartins@gmail.com>
 tallys <tallys@tallys.(none)>
+Thiago Zoroastro <thiago.zoroastro@bol.com.br>
 Valessio Brito <contato@valessiobrito.com.br>
 Valessio Brito <contato@valessiobrito.info>
 Valessio Brito <valessio@gmail.com>
@@ -0,0 +1,124 @@
+# Noosfero Development Policy
+
+## Developer Roles
+
+* *Developers* are everyone that is contributing code to Noosfero.
+* *Committers* are the people with direct commit access to the Noosfero source
+  code. They are responsible for reviewing contributions from other developers
+  and integrating them in the Noosfero code base. They are the members of the
+  [Noosfero group on Gitlab](https://gitlab.com/groups/noosfero/members).
+* *Release managers* are the people that are managing the release of a new
+  Noosfero version and/or the maintainance work of an existing Noosfero stable
+  branch. See MAINTAINANCE.md for details on the maintaince policy.
+
+## Development process
+
+* Every new feature or non-trivial bugfix should be reviewed by at least one
+  committer. This must be the case even if the original author is a committer.
+
+  * In the case the original author is a committer, he/she should feel free to
+    commit directly if after 1 week nobody has provided any kind of feedback.
+
+  * Developers who are not committers should feel free to ping committers if
+    they do not get feedback on their contributions after 1 week.
+
+    * On GitLab, one can just add a comment to the merge request; one can also
+      @-mention specific committers or other developers who have expertise on
+      the area of the contribution.
+
+  * Committers should follow the activity of the project, and try to help
+    reviewing contributions from others as much as possible.
+
+    * On GitLab one can get emails for all activity on a project by setting the
+      [notification settings](https://gitlab.com/profile/notifications) to
+      "watch".
+
+  * Anyone can help by reviewing contributions. Committers are the only ones
+    who can give the final approval to a contribution, but everyone is welcome
+    to help with code review, testing, etc.
+
+    * See note above about setting up notification on GitLab.
+
+* Committers should feel free to push trivial (or urgent) changes directly.
+  There are no strict rule on what makes a change trivial or urgent; committers
+  are expected to exercise good judgement on a case by case basis.
+
+  * Usually changes to the database are not trivial.
+
+* In the case of unsolvable conflict between commiters regarding any change to
+  the code, the current release manager(s) will have the final say in the
+  matter.
+
+* Release managers are responsible for stablishing a release schedule, and
+  about deciding when and what to release.
+
+  * Release managers should announce release schedules to the project mailing
+    lists in advance.
+
+  * The release schedule may include a period of feature freeze, during which
+    no new features or any other changes that are not pre-approved by the
+    release manager must be committed to the repository.
+
+  * Committers must respect the release schedule and feature freezes.
+
+## Maintainance process
+
+### Not all feature releases will be maintained as a stable release
+
+We will be choosing specific release series to be maintained as stable
+releases.
+
+This means that a given release is not guaranteed to be maintained as a stable
+release, but does *not* mean it won't be. Any committer (or anyone, really) can
+decide to maintain a given release as stable and seek help from others to do
+so.
+
+### No merges from stable branches to master
+
+*All* changes must be submitted against the master branch first, and when
+applicable, backported to the desired stable releases. Exceptions to this rules
+are bug fixes that only apply to a given stable branch and not to master.
+
+In the past we had non-trivial changes accepted into stable releases while
+master was way ahead (e.g. during the rails3 migration period), that made the
+merge back into master very painful.  By eliminating the need to do these
+merges, we save time for the people responsible for the release, and eliminate
+the possibility of human errors or oversights causing changes to be accepted
+into stable that will be a problem to merge back into master.
+
+By getting all fixes in master first, we improve the chances that  a future
+release will not present regressions against bugs that should already be fixed,
+but the fixes got lost in a big, complicated merge (and those won't exist
+anymore, at least not from stable branches to master).
+
+After a fix gets into master, backporting changes into a stable release branch
+is the responsibility of whoever is maintaing that branch, and those interested
+in it. The stable branch release manager(s) are entitled the final say on any
+matters related to that branch.
+
+## Apendix A: how to become a committer
+
+Every developer that wants to be a committer should create [an issue on
+Gitlab](https://gitlab.com/noosfero/noosfero/issues) requesting to be added as
+a committer. This request must include information about the requestor's
+previous contributions to the project.
+
+If 2 or more commiters consider second the request, the requestor is accepted
+as new commiter and added to the Noosfero group.
+
+The existing committers are free to choose whatever criteria they want to
+second the request, but they must be sure that the new committer is a
+responsible developer and knows what she/he is doing. They must be aware that
+seconding these requests means seconding the actions of the new committer: if
+the new committer screw up, her/his seconds screwed up.
+
+## Apendix B: how to become a release manager
+
+A new release manager for the development version of Noosfero (i.e. the one
+that includes new features, a.k.a. the master branch) is apointed by the
+current release manager, and must be a committer first.
+
+Release managers for stable branches are self-appointed, i.e. whoever takes the
+work takes the role. In case of a conflict (e.g. 2+ different people want to do
+the work but can't agree on working together), the development release manager
+decides.
@@ -10,7 +10,7 @@ module ContentViewerHelper
   end
   def number_of_comments(article)
-    display_number_of_comments(article.comments_count - article.spam_comments_count)
+    display_number_of_comments(article.comments_count - article.spam_comments_count.to_i)
   end
   def article_title(article, args = {})
@@ -5,7 +5,7 @@ development:
   addthis_pub: your-user-name
   addthis_logo: http://localhost:3000/images/logo-200x50.png
   addthis_options: favorites, email, digg, delicious, technorati, slashdot, twitter, more
-  gravatar: wavatar
+  gravatar: mm
   googlemaps_initial_zoom: 4
   exception_recipients: [admin@example.com]
   max_upload_size: 5MB
+noosfero (1.0) wheezy; urgency=low
+
+  * Noosfero 1.0 \o/
+
+ -- Antonio Terceiro <terceiro@colivre.coop.br>  Mon, 22 Dec 2014 10:52:21 -0300
+
 noosfero (1.0~rc4) wheezy-test; urgency=low
   * Fourth release candidate
 # See an example of this file at:
 # /usr/share/doc/noosfero/examples/
 production:
-  gravatar: wavatar
+  gravatar: mm
 module Noosfero
   PROJECT = 'noosfero'
-  VERSION = '1.0~rc4'
+  VERSION = '1.0'
 end
@@ -83,7 +83,7 @@ EOF
     begin
       File.open("AUTHORS.md", 'w') do |output|
         output.puts AUTHORS_HEADER
-        output.puts `git log --pretty=format:'%aN <%aE>' | sort | uniq`
+        output.puts `git log --no-merges --pretty=format:'%aN <%aE>' | sort | uniq`
         output.puts AUTHORS_FOOTER
       end
       commit_changes(['AUTHORS.md'], 'Updating authors file') if !pendencies_on_authors[:ok]
@@ -79,7 +79,22 @@ run(){
 _enable(){
   plugin="$1"
-  source="$available_plugins_dir/$plugin"
+
+  if [ -d "$available_plugins_dir/$plugin" ]; then
+    source="$available_plugins_dir/$plugin"
+    linksource="../../plugins/$plugin"
+  else
+    if [ ! -d "$plugin" ]; then
+      echo "E: $plugin not found (needs to be an existing directory)"
+      return
+    fi
+
+    # out-of-tree plugins
+    source="$plugin"
+    linksource="$source"
+    plugin=$(basename "$plugin")
+  fi
+
   target="$enabled_plugins_dir/$plugin"
   base="$base_plugins_dir/$plugin"
   run "$source/before_enable.rb"
@@ -110,7 +125,7 @@ _enable(){
       fi
     fi
     if [ "$installation_ok" = true ] && [ "$dependencies_ok" = true ]; then
-      ln -s "$source" "$target"
+      ln -s "$linksource" "$target"
       plugins_public_dir="$NOOSFERO_DIR/public/plugins"
       plugins_features_dir="$NOOSFERO_DIR/features/plugins"
       test -d "$target/public" && ln -s "$target/public" "$plugins_public_dir/$plugin"
@@ -83,6 +83,14 @@ class ContentViewerHelperTest &lt; ActionView::TestCase
     assert_equal '', result
   end
+  should 'not crash if spam_comments_count is nil' do
+    article = TextileArticle.new(:name => 'post for test', :body => 'post for test', :profile => profile)
+    article.stubs(:comments_count).returns(10)
+    article.stubs(:spam_comments_count).returns(nil)
+    result = number_of_comments(article)
+    assert_match /10 comments/, result
+  end
+
   should 'not list feed article' do
     profile.articles << build(Blog, :name => 'Blog test', :profile => profile)
     assert_includes profile.blog.children.map{|i| i.class}, RssFeed
@@ -76,3 +76,6 @@ else
   apt-cache policy noosfero
   apt-get install -qy noosfero noosfero-apache
 fi
+
+a2dissite 000-default
+service apache2 reload
@@ -0,0 +1,124 @@		@@ -0,0 +1,124 @@
	1	+# Noosfero Development Policy
	2	+
	3	+## Developer Roles
	4	+
	5	+* Developers are everyone that is contributing code to Noosfero.
	6	+* Committers are the people with direct commit access to the Noosfero source
	7	+ code. They are responsible for reviewing contributions from other developers
	8	+ and integrating them in the Noosfero code base. They are the members of the
	9	+ [Noosfero group on Gitlab](https://gitlab.com/groups/noosfero/members).
	10	+* Release managers are the people that are managing the release of a new
	11	+ Noosfero version and/or the maintainance work of an existing Noosfero stable
	12	+ branch. See MAINTAINANCE.md for details on the maintaince policy.
	13	+
	14	+## Development process
	15	+
	16	+* Every new feature or non-trivial bugfix should be reviewed by at least one
	17	+ committer. This must be the case even if the original author is a committer.
	18	+
	19	+ * In the case the original author is a committer, he/she should feel free to
	20	+ commit directly if after 1 week nobody has provided any kind of feedback.
	21	+
	22	+ * Developers who are not committers should feel free to ping committers if
	23	+ they do not get feedback on their contributions after 1 week.
	24	+
	25	+ * On GitLab, one can just add a comment to the merge request; one can also
	26	+ @-mention specific committers or other developers who have expertise on
	27	+ the area of the contribution.
	28	+
	29	+ * Committers should follow the activity of the project, and try to help
	30	+ reviewing contributions from others as much as possible.
	31	+
	32	+ * On GitLab one can get emails for all activity on a project by setting the
	33	+ [notification settings](https://gitlab.com/profile/notifications) to
	34	+ "watch".
	35	+
	36	+ * Anyone can help by reviewing contributions. Committers are the only ones
	37	+ who can give the final approval to a contribution, but everyone is welcome
	38	+ to help with code review, testing, etc.
	39	+
	40	+ * See note above about setting up notification on GitLab.
	41	+
	42	+* Committers should feel free to push trivial (or urgent) changes directly.
	43	+ There are no strict rule on what makes a change trivial or urgent; committers
	44	+ are expected to exercise good judgement on a case by case basis.
	45	+
	46	+ * Usually changes to the database are not trivial.
	47	+
	48	+* In the case of unsolvable conflict between commiters regarding any change to
	49	+ the code, the current release manager(s) will have the final say in the
	50	+ matter.
	51	+
	52	+* Release managers are responsible for stablishing a release schedule, and
	53	+ about deciding when and what to release.
	54	+
	55	+ * Release managers should announce release schedules to the project mailing
	56	+ lists in advance.
	57	+
	58	+ * The release schedule may include a period of feature freeze, during which
	59	+ no new features or any other changes that are not pre-approved by the
	60	+ release manager must be committed to the repository.
	61	+
	62	+ * Committers must respect the release schedule and feature freezes.
	63	+
	64	+## Maintainance process
	65	+
	66	+### Not all feature releases will be maintained as a stable release
	67	+
	68	+We will be choosing specific release series to be maintained as stable
	69	+releases.
	70	+
	71	+This means that a given release is not guaranteed to be maintained as a stable
	72	+release, but does not mean it won't be. Any committer (or anyone, really) can
	73	+decide to maintain a given release as stable and seek help from others to do
	74	+so.
	75	+
	76	+### No merges from stable branches to master
	77	+
	78	+All changes must be submitted against the master branch first, and when
	79	+applicable, backported to the desired stable releases. Exceptions to this rules
	80	+are bug fixes that only apply to a given stable branch and not to master.
	81	+
	82	+In the past we had non-trivial changes accepted into stable releases while
	83	+master was way ahead (e.g. during the rails3 migration period), that made the
	84	+merge back into master very painful. By eliminating the need to do these
	85	+merges, we save time for the people responsible for the release, and eliminate
	86	+the possibility of human errors or oversights causing changes to be accepted
	87	+into stable that will be a problem to merge back into master.
	88	+
	89	+By getting all fixes in master first, we improve the chances that a future
	90	+release will not present regressions against bugs that should already be fixed,
	91	+but the fixes got lost in a big, complicated merge (and those won't exist
	92	+anymore, at least not from stable branches to master).
	93	+
	94	+After a fix gets into master, backporting changes into a stable release branch
	95	+is the responsibility of whoever is maintaing that branch, and those interested
	96	+in it. The stable branch release manager(s) are entitled the final say on any
	97	+matters related to that branch.
	98	+
	99	+## Apendix A: how to become a committer
	100	+
	101	+Every developer that wants to be a committer should create [an issue on
	102	+Gitlab](https://gitlab.com/noosfero/noosfero/issues) requesting to be added as
	103	+a committer. This request must include information about the requestor's
	104	+previous contributions to the project.
	105	+
	106	+If 2 or more commiters consider second the request, the requestor is accepted
	107	+as new commiter and added to the Noosfero group.
	108	+
	109	+The existing committers are free to choose whatever criteria they want to
	110	+second the request, but they must be sure that the new committer is a
	111	+responsible developer and knows what she/he is doing. They must be aware that
	112	+seconding these requests means seconding the actions of the new committer: if
	113	+the new committer screw up, her/his seconds screwed up.
	114	+
	115	+## Apendix B: how to become a release manager
	116	+
	117	+A new release manager for the development version of Noosfero (i.e. the one
	118	+that includes new features, a.k.a. the master branch) is apointed by the
	119	+current release manager, and must be a committer first.
	120	+
	121	+Release managers for stable branches are self-appointed, i.e. whoever takes the
	122	+work takes the role. In case of a conflict (e.g. 2+ different people want to do
	123	+the work but can't agree on working together), the development release manager
	124	+decides.
	@@ -10,7 +10,7 @@ module ContentViewerHelper		@@ -10,7 +10,7 @@ module ContentViewerHelper
10	end	10	end
11		11
12	def number_of_comments(article)	12	def number_of_comments(article)
13	- display_number_of_comments(article.comments_count - article.spam_comments_count)	13	+ display_number_of_comments(article.comments_count - article.spam_comments_count.to_i)
14	end	14	end
15		15
16	def article_title(article, args = {})	16	def article_title(article, args = {})
	@@ -5,7 +5,7 @@ development:		@@ -5,7 +5,7 @@ development:
5	addthis_pub: your-user-name	5	addthis_pub: your-user-name
6	addthis_logo: http://localhost:3000/images/logo-200x50.png	6	addthis_logo: http://localhost:3000/images/logo-200x50.png
7	addthis_options: favorites, email, digg, delicious, technorati, slashdot, twitter, more	7	addthis_options: favorites, email, digg, delicious, technorati, slashdot, twitter, more
8	- gravatar: wavatar	8	+ gravatar: mm
9	googlemaps_initial_zoom: 4	9	googlemaps_initial_zoom: 4
10	exception_recipients: [admin@example.com]	10	exception_recipients: [admin@example.com]
11	max_upload_size: 5MB	11	max_upload_size: 5MB
		1	+noosfero (1.0) wheezy; urgency=low
		2	+
		3	+ * Noosfero 1.0 \o/
		4	+
		5	+ -- Antonio Terceiro <terceiro@colivre.coop.br> Mon, 22 Dec 2014 10:52:21 -0300
		6	+
1	noosfero (1.0~rc4) wheezy-test; urgency=low	7	noosfero (1.0~rc4) wheezy-test; urgency=low
2		8
3	* Fourth release candidate	9	* Fourth release candidate
1	# See an example of this file at:	1	# See an example of this file at:
2	# /usr/share/doc/noosfero/examples/	2	# /usr/share/doc/noosfero/examples/
3	production:	3	production:
4	- gravatar: wavatar	4	+ gravatar: mm
1	module Noosfero	1	module Noosfero
2	PROJECT = 'noosfero'	2	PROJECT = 'noosfero'
3	- VERSION = '1.0~rc4'	3	+ VERSION = '1.0'
4	end	4	end
	@@ -83,7 +83,7 @@ EOF		@@ -83,7 +83,7 @@ EOF
83	begin	83	begin
84	File.open("AUTHORS.md", 'w') do \|output\|	84	File.open("AUTHORS.md", 'w') do \|output\|
85	output.puts AUTHORS_HEADER	85	output.puts AUTHORS_HEADER
86	- output.puts `git log --pretty=format:'%aN <%aE>' \| sort \| uniq`	86	+ output.puts `git log --no-merges --pretty=format:'%aN <%aE>' \| sort \| uniq`
87	output.puts AUTHORS_FOOTER	87	output.puts AUTHORS_FOOTER
88	end	88	end
89	commit_changes(['AUTHORS.md'], 'Updating authors file') if !pendencies_on_authors[:ok]	89	commit_changes(['AUTHORS.md'], 'Updating authors file') if !pendencies_on_authors[:ok]
	@@ -79,7 +79,22 @@ run(){		@@ -79,7 +79,22 @@ run(){
79		79
80	_enable(){	80	_enable(){
81	plugin="$1"	81	plugin="$1"
82	- source="$available_plugins_dir/$plugin"	82	+
		83	+ if [ -d "$available_plugins_dir/$plugin" ]; then
		84	+ source="$available_plugins_dir/$plugin"
		85	+ linksource="../../plugins/$plugin"
		86	+ else
		87	+ if [ ! -d "$plugin" ]; then
		88	+ echo "E: $plugin not found (needs to be an existing directory)"
		89	+ return
		90	+ fi
		91	+
		92	+ # out-of-tree plugins
		93	+ source="$plugin"
		94	+ linksource="$source"
		95	+ plugin=$(basename "$plugin")
		96	+ fi
		97	+
83	target="$enabled_plugins_dir/$plugin"	98	target="$enabled_plugins_dir/$plugin"
84	base="$base_plugins_dir/$plugin"	99	base="$base_plugins_dir/$plugin"
85	run "$source/before_enable.rb"	100	run "$source/before_enable.rb"
	@@ -110,7 +125,7 @@ _enable(){		@@ -110,7 +125,7 @@ _enable(){
110	fi	125	fi
111	fi	126	fi
112	if [ "$installation_ok" = true ] && [ "$dependencies_ok" = true ]; then	127	if [ "$installation_ok" = true ] && [ "$dependencies_ok" = true ]; then
113	- ln -s "$source" "$target"	128	+ ln -s "$linksource" "$target"
114	plugins_public_dir="$NOOSFERO_DIR/public/plugins"	129	plugins_public_dir="$NOOSFERO_DIR/public/plugins"
115	plugins_features_dir="$NOOSFERO_DIR/features/plugins"	130	plugins_features_dir="$NOOSFERO_DIR/features/plugins"
116	test -d "$target/public" && ln -s "$target/public" "$plugins_public_dir/$plugin"	131	test -d "$target/public" && ln -s "$target/public" "$plugins_public_dir/$plugin"
	@@ -83,6 +83,14 @@ class ContentViewerHelperTest < ActionView::TestCase		@@ -83,6 +83,14 @@ class ContentViewerHelperTest < ActionView::TestCase
83	assert_equal '', result	83	assert_equal '', result
84	end	84	end
85		85
		86	+ should 'not crash if spam_comments_count is nil' do
		87	+ article = TextileArticle.new(:name => 'post for test', :body => 'post for test', :profile => profile)
		88	+ article.stubs(:comments_count).returns(10)
		89	+ article.stubs(:spam_comments_count).returns(nil)
		90	+ result = number_of_comments(article)
		91	+ assert_match /10 comments/, result
		92	+ end
		93	+
86	should 'not list feed article' do	94	should 'not list feed article' do
87	profile.articles << build(Blog, :name => 'Blog test', :profile => profile)	95	profile.articles << build(Blog, :name => 'Blog test', :profile => profile)
88	assert_includes profile.blog.children.map{\|i\| i.class}, RssFeed	96	assert_includes profile.blog.children.map{\|i\| i.class}, RssFeed
	@@ -76,3 +76,6 @@ else		@@ -76,3 +76,6 @@ else
76	apt-cache policy noosfero	76	apt-cache policy noosfero
77	apt-get install -qy noosfero noosfero-apache	77	apt-get install -qy noosfero noosfero-apache
78	fi	78	fi
		79	+
		80	+a2dissite 000-default
		81	+service apache2 reload